Weather Disruptions Module

[RachelMurray-Watson]

This PR aims to develop a separate "WeatherDisruptions" module. This modularizes code developed in rmw/climate_change_switch and rmw/climate_troubleshoot_LHS.

The module aims to do the following:

1. Assign individuals facilities based on their districts*
2. Read in data on the weather disruptions**
3. Determine whether a disruption will occur (and consequence e.g. reseeking healthcare)
4. Feed this back to the health system
5. Log disrupted HSIs by district

• This is a necessary but, also, distinct functionality that could instead be included in the demography module.
  ** Currently these are csv files with the proportion of ANC appointments disrupted for each facility by month. @marghe-molaro previously suggested saving the coefficients of the ANC model instead and doing the LM each time. This will probably save us space (as we would only need the details for each facility to be loaded in) but it seems more computationally intensive (as would need to look up all details for each facility and do calculation each time a HSI is processed).

To Do:

• Framework of WeatherDisruptions module
• Parameter file separated from health system file
• Tests of functionality
• Decide on points * and ** above
• Add new logging to HealthBurden module

[marghe-molaro]

Hi @RachelMurray-Watson,

Great to see this being formalised this way!

Just a few comments:

1. Agreed
2. You can initialise the disruption dfs upon initialisation of the module based on the specified coefficients without any repercussions on simulation runtime. (Basically, instead of reading in your 'look up' climate disruption df, you 'create it' based on the coefficients and any other relevant info (e.g. climate projections, facility location, ...) upon initialisation - unless I am missing something)
   Advantages:

• Reduce resource files required (now you only need the climate projections)
• Make your assumptions around how climate relates to disruptions more explicit (i.e. you declare coefficients explicitly) and therefore amenable to modifications later on;

[RachelMurray-Watson]

Hi @RachelMurray-Watson,

Great to see this being formalised this way!

Just a few comments:

1. Agreed
2. You can initialise the disruption dfs upon initialisation of the module based on the specified coefficients without any repercussions on simulation runtime. (Basically, instead of reading in your 'look up' climate disruption df, you 'create it' based on the coefficients and any other relevant info (e.g. climate projections, facility location, ...) upon initialisation - unless I am missing something)
   Advantages:

• Reduce resource files required (now you only need the climate projections)
• Make your assumptions around how climate relates to disruptions more explicit (i.e. you declare coefficients explicitly) and therefore amenable to modifications later on;

Ah I see! I misinterpreted what you meant initially. Grand so, I can do it that way.

[RachelMurray-Watson]

Hi @RachelMurray-Watson,
Great to see this being formalised this way!
Just a few comments:

1. Agreed
2. You can initialise the disruption dfs upon initialisation of the module based on the specified coefficients without any repercussions on simulation runtime. (Basically, instead of reading in your 'look up' climate disruption df, you 'create it' based on the coefficients and any other relevant info (e.g. climate projections, facility location, ...) upon initialisation - unless I am missing something)
   Advantages:

• Reduce resource files required (now you only need the climate projections)
• Make your assumptions around how climate relates to disruptions more explicit (i.e. you declare coefficients explicitly) and therefore amenable to modifications later on;

Ah I see! I misinterpreted what you meant initially. Grand so, I can do it that way.

Actually @marghe-molaro I am unsure it does reduce the files, as for each scenario I still need to read in the precipitation files (which still gives one for model for each scenario). However, for your point about transparency, I think it is still worthwhile.

[marghe-molaro]

Hi @RachelMurray-Watson,
Great to see this being formalised this way!
Just a few comments:

1. Agreed
2. You can initialise the disruption dfs upon initialisation of the module based on the specified coefficients without any repercussions on simulation runtime. (Basically, instead of reading in your 'look up' climate disruption df, you 'create it' based on the coefficients and any other relevant info (e.g. climate projections, facility location, ...) upon initialisation - unless I am missing something)
   Advantages:

• Reduce resource files required (now you only need the climate projections)
• Make your assumptions around how climate relates to disruptions more explicit (i.e. you declare coefficients explicitly) and therefore amenable to modifications later on;

Ah I see! I misinterpreted what you meant initially. Grand so, I can do it that way.

Actually @marghe-molaro I am unsure it does reduce the files, as for each scenario I still need to read in the precipitation files (which still gives one for model for each scenario). However, for your point about transparency, I think it is still worthwhile.

Oh I see, so before you weren't loading the precipitation files at all, only the pre-computed disruptions in that scenario?

I think this way is still more future-proof, because later on you might want to link precipitation to a number of other things (e.g. specific risks to flooding, food security, etc) as well as making assumptions more explicit. But point taken!