Improvements for consistency

[jcblemai]

Among other changes:

Interventions

changed

• Reduce > SinglePeriodModifier
• MultiTimeReduce > MultiPeriodModifier
• ReduceIntervention > ModifierModifier
• Stacked > StackedModifier

and removed ReduceR0

geoid:

change geoid to subpop
affected_geoids > subpop
place > subpop

Initial Conditions

SetInitialCondition comp changed to mc_name

Fitting initial conditions

initial_conditions:
method: SetInitialConditionsFolderDraw
seeding_file_type: init
perturbation:
distribution: truncnorm
mean: 0
sd: 0.02
a: -1
b: 1
and in the initial initial condition files are csvs or parquet like
subpop,mc_name,amount,pertub
AK, R_age_01_19, .3, TRUE
AK, S_age_01_19, remain, FALSE
...

TODO

• Make each component of the config not necessary for a gempor run/setup object
• remove the ability to use several scenarios
• Make outcomes intervention their own section so they don't come before outcomes (Or not ? I like having all modifiers at the same place)
• change interventions::settings::template is a bit weird, can’t we just say “method” as that’s the word we use for seeding and initial conditions and outcomes.
• we confuse the word “scenario” and “intervention” a few times in config notation. Under intervention::scenario you name a few scenarios, then under interventions::settings you name a few interventions. T
• get rid of stacked interventions ?
• change setup.py name to obey convention
• Make the setup class the only user of the full config

Useful messages

https://iddynamicsjhu.slack.com/archives/GU0SBC2AC/p1693600672108579?thread_ts=1693399856.162839&cid=GU0SBC2AC Alison
https://iddynamicsjhu.slack.com/archives/GU0SBC2AC/p1693223628997289 Koji

[alsnhll]

Adding some updates to the proposed to-dos

Change order of config sections to:

• spatial_setup
• compartments
• seir
• initial_conditions
• seeding
• outcomes
• interventions
• inference

For Outcomes and Interventions sections:

Proposed changes to make it easier to understand the intervention/scenario definitions. First, need to decide if it's worth having the ability to re-run the outcomes part only without re-running the full SEIR model.

• For either case

  • (currently have) interventions can include interventions on any SEIR or Outcome parameter
  • (change) put outcomes before interventions in config sections, just for logical consistency
  • (change) "Intervention scenarios" are either one or more intervention, and REPLACE the idea of stacked interventions (Either get rid of the StackedModifier template and instead define the interventions to combine in the interventions::scenario section, OR, if you keep StackedModifier, rename the "scenario" option within it to "interventions")

• If NOT (change)

  • Remove outcome scenarios. Scenarios are for interventions only. A new config would be needed if you want to change the baseline values of outcome parameters.

• If SO (Current)

  • Call interventions::scenarios something different than outcome::scenarios. interventions_scenarios define named combinations of interventions (which are time-dependent alterations to any SEIR or Outcome parameter), while outcome_scenarios define completely new sets of time-INdependent (aka baseline) values for Outcome parameters
  • The config should re-run for every combination of an intervention scenario and outcome scenario (so if 2 intervention scenarios and 2 outcome scenarios, it will have to run 2x2 = 4 times)

For interventions section

• Consider changing the valence/sign of interventions. Currently, if the value is given as positive, this results in a REDUCTION of the parameter. This made sense when the interventions were called REDUCE, but now they are called MODIFY, so it is confusing that the default is negative and if you want an increase, you have to give a NEGATIVE value.
• In ModifierModifier, change the name of baseline_scenario to baseline_intervention

[jcblemai]

Bringing here the improvements for config V3

Config Structure changes

The concept of scenario for outcomes is phased out. One config = One structure. Only modifiers can be changed.

The configs sections are described below. There are four types of runs but users should only be advised to do either (seir+outcomes) or (seir+outcomes+inference).

• Just seir
• Just outcomes on some already generated seir files > This is not recommended, but it works (and useful for tests)
• both seir and outcomes
  • in this case we can optionally run inference.

subpop_setup                 # Always required
compartments                  # Required if running seir
seir                          # Required if running seir
initial_conditions            # One of seeding or initial_conditions is required when running seir
seeding                       # One of seeding or initial_conditions is required when running seir
outcomes                      # Required if running outcomes
seir_modifiers                # Not required. If exists, every modifier will be applied to seir parameters
outcomes_modifiers            # Not required. If exists, every modifier will be applied to outcomes parameters
inference                     # Required if running inference

So what is the purpose of the StackedModifier if every intervention is applied ?

we keep if for debugging purposes: useful so you can ask gempyor to plot seaonality only or NPI or else.

Note that the config elements can be put in any order

So how do the new modifiers sections work. There are two possibilities:
A. Simple config (one config = one run, no modifiers scenarios)
if the key scenarios: is not present under modifiers_seir or modifiers_outcomes, then All modifiers under this sections are runs.

{seir,outcomes}_modifiers:
  modifier1:
    ....
  modifier2:
    ....
  ....

B. Multiple scenarios config
if the key scenarios: is present under modifiers_seir or modifiers_outcomes, then the user can specify a scenario to be run at runtime. Only modifiers under this scenario are runs.
If the user does not specify a scenario, all combinations of modifiers_seir and modifiers_outcomes are runs (2 of each makes 4 runs)

{seir,outcomes}_modifiers:
  scenarios:
    - scenario1
    - scenario2
  modifiers:
    modifier1:
      ....
    modifier2:
      ....
    ....
  scenario1:
  method: StackedModifier
  modifiers: ["modifier1", "modifier2"]

substructure:

Outcomes

outcomes:
  outcomes:   # before this >settings<
    [individual outcomes]

Probabilities

The distribution: fixed can be omitted:

alpha:
      value:
        distribution: fixed
        value: .99

is still valid but can be abbreviated

alpha:
      value: .99

this applies to all probabilities distributions for gempyor: modifiers, outcomes, parameters, ...

Nomenclature changes

Interventions

changed

• Reduce > SinglePeriodModifier
• MultiTimeReduce > MultiPeriodModifier
• ReduceIntervention > ModifierModifier
• Stacked > StackedModifier

and removed ReduceR0

The template is now called method to be consistent with initial_conditions.
In a StackedModifiers the different scenario used to be listed under scenarios -> this has been changed to modifiers
For a ModifierModifier, baseline_scenario has changed to baseline_modifer

For outcomes intervention_param_name has been changed to modifier_parameter

geoid:

change geoid to subpop
affected_geoids > subpop
place > subpop

For spatial_setup, popnode_key is deprecated (always population) and codenames is deprecated (always subpop)

Outcomes

duration_name > outcome_prevalence_name

Initial Conditions

SetInitialCondition comp changed to mc_name

Fitting initial conditions

initial_conditions:
method: SetInitialConditionsFolderDraw
seeding_file_type: init
perturbation:
distribution: truncnorm
mean: 0
sd: 0.02
a: -1
b: 1
and in the initial initial condition files are csvs or parquet like
subpop,mc_name,amount,pertub
AK, R_age_01_19, .3, TRUE
AK, S_age_01_19, remain, FALSE
...

Parameters:

timeserie > timeseries
intervention_overlap_operation > stacked_modifier_method

Filestructure:

we don't nest scenarios in folder (e.g {setup_name}/{npi_scenario}/...
now we have a single folder depth /{setup_name}_{seir_modifiers_scenario}_{outcome_modifiers_scenario}/. if one of the modifier scenario does not exist (cause no modifiers for e.g seir, or because no scenario for said modifiers) then we just don't write it.

TODO

• Make each component of the config not necessary for a gempor run/setup object
• remove the ability to use several scenarios
• Make outcomes intervention their own section so they don't come before outcomes (Or not ? I like having all modifiers at the same place)
• change interventions::settings::template is a bit weird, can’t we just say “method” as that’s the word we use for seeding and initial conditions and outcomes.
• we confuse the word “scenario” and “intervention” a few times in config notation. Under intervention::scenario you name a few scenarios, then under interventions::settings you name a few interventions. T
• get rid of stacked interventions ? -> no, useful for debuging purpose
• change setup.py name to obey convention
• Make the setup class the only user of the full config
• implemet the simple configs

from @alsnhll in #62

• Change order of config sections -> Done, any order works
• decide if it's worth having the ability to re-run the outcomes part only without re-running the full SEIR model -> yes, for testing at least. But not recommended for users (it works, but it's confusing to teach)
• Remove outcome scenarios -> done
• Call interventions::scenarios something different than outcome::scenarios

Useful messages

https://iddynamicsjhu.slack.com/archives/GU0SBC2AC/p1693600672108579?thread_ts=1693399856.162839&cid=GU0SBC2AC Alison
https://iddynamicsjhu.slack.com/archives/GU0SBC2AC/p1693223628997289 Koji

BIG TODO that needs discussion

From Alison:
Consider changing the valence/sign of interventions. Currently, if the value is given as positive, this results in a REDUCTION of the parameter. This made sense when the interventions were called REDUCE, but now they are called MODIFY, so it is confusing that the default is negative and if you want an increase, you have to give a NEGATIVE value.
In ModifierModifier, change the name of baseline_scenario to baseline_intervention