Weather Disruptions Module by RachelMurray-Watson · Pull Request #1790 · UCL/TLOmodel

RachelMurray-Watson · 2026-01-29T09:30:28Z

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:

Assign individuals facilities based on their districts*
Read in data on the weather disruptions**
Determine whether a disruption will occur (and consequence e.g. reseeking healthcare)
Feed this back to the health system
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

…n code developed in rmw/climate_change_switch and rmw/climate_troubleshoot_LHS.

marghe-molaro · 2026-01-29T09:45:20Z

Hi @RachelMurray-Watson,

Great to see this being formalised this way!

Just a few comments:

Agreed
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 · 2026-01-29T09:55:30Z

Hi @RachelMurray-Watson,

Great to see this being formalised this way!

Just a few comments:

Agreed

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 · 2026-01-29T10:06:15Z

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

Agreed

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 · 2026-01-29T14:00:57Z

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

Agreed

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!

…e linear model.

…rameters needed to determine (a) drop in HSI appointments (from linear model) and (b) if disruption will occur, nature of disruption. Additionally including the precipitation files for 245 low/medium/high models

… models

…ded for the weather disruptions). Uses code from rmw/climate_health_switch and rmw/climate_troublesheet_LHS. Also records population by district.

…ear model of HSI disruptions.

Renamed files for clarity In params file for WeatherDisruptions, removed duplicated params

Also renamed first column for read-in by csv files

Initial code for LM *not working yet*

… added in the South West predictor Added index to ensure the first 12 months were used, then skipped (2024, so needed to calculate lag)

…dded to the queue, but all gandled internally to the module. Updated too so that the list is not just essential equipment, but "meets all conditions" (not weatehr disrupted, has equipment).

Added reset of counters (could all go into one log??) Changed linear model to remove month - see not on parameter commit Handling on NAN Added check_for_hsi_disruption check if conditions are met, to call the linear model to calculate the disruptions _handle_disruption determines if the disruption is supply or demand side, if mode 2, deducts from daily capabilities _determine_reschudling handles the healthcare seeking behaviour post-disruption _calculate_delay determines what the number of days delay there will be

# Conflicts: # src/tlo/methods/healthsystem.py

Also add in handling of climate disruptions in mode 2

… facilities

Added in tests of logging, scale factors, assigning facilities, mode 2 capabilities reduction

…erested in disruptions, i.e. decrease in attendance, only).

…lth/year) structure; move district tracking to separate 5-level dataframes to preserve existing test compatibility

Also updated local_run_analysis to be self-contained.

Removed unused import of weather_disruptions from tlo.methods.

RachelMurray-Watson · 2026-04-10T15:50:56Z

I think this is finally ready for its initial review @marghe-molaro !

marghe-molaro

I'm just including a few comments for now.

Main thing to note at present is that this PR seems to be introducing a large number of potentially unwanted changes to the HealthSystem (e.g. removing all module parameters)

marghe-molaro · 2026-04-16T09:05:43Z

    # We should have 21 age range categories
    assert len(AGE_RANGE_CATEGORIES) == 21

-    # Here we declare parameters for this module. Each parameter has a name, data type,


Wondering why this description was removed in this PR?

marghe-molaro · 2026-04-16T09:12:19Z

            categories=['SET_AT_RUNTIME']
        ),

+        # Facility level assignments; categories are set in `pre_initialise_population`


In an ideal world, we would look up facility levels declared in the HS module and then declare this dynamically. e.g. if in the HS facility levels declared are facility_levels = ["0", "1a", "1b", "2", "3"], you would create an array of properties, called something like assigned_real_facility_for_facility_level, and populate it later based on of length facility_levels, where assigned_real_facility_for_facility_level[0] refers to facility level facility_level[0]. Might not be the time to do this now, but could you add a note on this on the HealthSystem review doc?

marghe-molaro · 2026-04-16T09:29:32Z

        )

+        # Map each TLO facility level to the facility types it encompasses
+        facility_levels_types = {


Similarly to comment above, this should come from the HS, i.e. not be redefined here. Not sure why you need this info?

marghe-molaro · 2026-04-16T12:11:47Z

        _district_of_residence = df.at[_id_inherit_from, 'district_of_residence']
        _region_of_residence = df.at[_id_inherit_from, 'region_of_residence']

+        # Inherit facility assignments from parent


This seems a bit verbose/unnecessary if only used here, you can just call directly?

marghe-molaro · 2026-04-16T12:14:01Z

            'cause': str(cause),
            'label': self.causes_of_death[cause].label,
            'person_id': individual_id,
+            'district_of_residence': person['district_of_residence'],


Is this a change that we want to bring into master for sure? Or more relevant to your particular analysis?

marghe-molaro · 2026-04-16T12:45:38Z

    symptommanager,
    tb,
    wasting,
+    weather_disruptions,


I'm not actually 100% sure we want the weather_disruptions to be included in the full model for now. I think a user interested in including them could more simply invoke the fullmodel and add the weather_disruptions module in the scenario file, unless we want to make weather disruptions a standard component of the full model. @tbhallett is better placed to advise.

If we do want to include this module in the full model, I suggest always including it and then declaring a parameter in that module e.g. include_weather_disruptions to decide whether they are considered or not. I think use_simplified_births option when invoking the full model is mainly used to ensure mutually exclusive sets of modules (simplified births vs everything else maternity/neonatal related) are not included at the same time

marghe-molaro · 2026-04-16T12:54:36Z

@@ -404,44 +404,6 @@ def __init__(
        disable_and_reject_all: bool = False,
        hsi_event_count_log_period: Optional[str] = "month",
    ):
-        """


I'm a bit confused, it looks like you are removing all the HealthSystem parameters here, but not re-adding them? It must be a weird git glitch

marghe-molaro · 2026-04-16T12:55:28Z

@@ -544,20 +506,12 @@ def __init__(

        self._hsi_event_count_log_period = hsi_event_count_log_period
        if hsi_event_count_log_period in {"day", "month", "year", "simulation"}:
-            # Counters for binning HSI events run (by unique integer keys) over


It looks like there are a lot of comments that are being removed from the HealthSystem module...just wondering why?

marghe-molaro · 2026-04-16T13:05:03Z

                    original_call = next_event_tuple.hsi_event.expected_time_requests
                    _priority = next_event_tuple.priority

-                    # Check if any of the officers required have run out.
+                    climate_disrupted = False
+                    if 'WeatherDisruptions' in self.sim.modules:


Going back to the 'fullmodel' comment: this would be suboptimal because this would always be true by default. But if following my first suggestion (i.e. we don't need the WeatherDisruptions in the fullmodel) then absolutely fine

marghe-molaro · 2026-04-16T13:11:50Z

+                            self.sim.modules['WeatherDisruptions'].check_hsi_for_disruption(
+                                hsi_event_item=next_event_tuple,
+                                current_date=self.sim.date
+                            ) if 'WeatherDisruptions' in self.sim.modules else (False, False)


Same as above

New module that handles weather disruptions in the TLO model. Based o…

97d7f1f

…n code developed in rmw/climate_change_switch and rmw/climate_troubleshoot_LHS.

RachelMurray-Watson added 25 commits January 29, 2026 14:07

Added in reading of parameters, including ones needed for creating th…

9897b95

…e linear model.

Including the precipitation files for ssp126 and 585 low/medium/high…

30be6ba

… models

Adding in assignation of facilities to individuals using cKDTree (nee…

4ce9e7a

…ded for the weather disruptions). Uses code from rmw/climate_health_switch and rmw/climate_troublesheet_LHS. Also records population by district.

Resource file from rmw/climate_change_health with data needed for lin…

3d63fc4

…ear model of HSI disruptions.

Renamed

e65cdd4

Added in weather_disruptions to full model. Default is not on.

9e47f85

Added worldpop files for demography

16e7d39

Renamed files for clarity In params file for WeatherDisruptions, removed duplicated params

Updated paths

bbe6a84

Included Weather Disruptions w/o if statement

1aed208

Renamed variables for clarity

caa9fed

Also renamed first column for read-in by csv files

Added in coefficients for model as parameters

3261340

Initial code for LM *not working yet*

Added logging for regional DALYs and YLL

fef6f3f

Added in month as a coefficient

1d0d270

Fixed so that the continuous variables were multiplied correctly also…

5e2ba3f

… added in the South West predictor Added index to ensure the first 12 months were used, then skipped (2024, so needed to calculate lag)

Added month coef

95629d0

Increase accuracy of some coef

625c8c3

Formatting

fc9ac95

Fixed indenting to ensure logging worked

3faf104

Added in link to the WeatherDisruption module. Now does checks once a…

32d2c2c

…dded to the queue, but all gandled internally to the module. Updated too so that the list is not just essential equipment, but "meets all conditions" (not weatehr disrupted, has equipment).

Checking behaviour

a18b389

Merge branch 'refs/heads/master' into rmw/climate_change_module

a832a5e

# Conflicts: # src/tlo/methods/healthsystem.py

*** REMOVING FILES FROM GIT LFS ***

e4d0ef8

Update from master

6fc2d68

Also add in handling of climate disruptions in mode 2

RachelMurray-Watson and others added 28 commits March 6, 2026 16:40

unused import

5c3a31e

File for testing local runs

f62b932

Added checking if supply or demand side and updating capabilities for…

c082dc3

… facilities

Added scale factor for urgency

8602b05

Added test script

2a4944c

isort

436cd82

Tidied up comments, unneccessary checks/print statements

7aee745

Refactored logic to minimise code duplication

26c1868

Added in tests of logging, scale factors, assigning facilities, mode 2 capabilities reduction

Refactored logic to minimise code duplication

72b2d5f

Added in tests of logging, scale factors, assigning facilities, mode 2 capabilities reduction

Re-introduced clipping of probabilities as was done in ANC paper (int…

a02be94

…erested in disruptions, i.e. decrease in attendance, only).

Fixed bug - parameters were being incorrectly overridden.

cab47b9

Merge branch 'master' into rmw/climate_change_module

209e119

Return to default

bea9c02

Return to default

03f7628

Return to default

507e08b

Return to default

817091a

Ensure dtypes are correct

a23611e

isort src tests

b62f2a8

Fix HealthBurden multi-index to restore 4-level (sex/age_range/li_wea…

0d703f3

…lth/year) structure; move district tracking to separate 5-level dataframes to preserve existing test compatibility

Fixed determinism issue

5c55a5e

Fixed determinism issue

8f1eb8b

Add in more secure check for year

cb910a8

Ensured climate logging actually happens as expected

0ade703

Rename file

9acf68b

Also updated local_run_analysis to be self-contained.

fixed date so disruptions would actually run

e370ee6

Refactor print statements for weather disruption analysis

7c806a7

Fix print statement formatting in simulation summary

1ccefc1

Remove unused import in local_run_analysis.py

464852a

Removed unused import of weather_disruptions from tlo.methods.

marghe-molaro requested changes Apr 16, 2026

View reviewed changes

Conversation

RachelMurray-Watson commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marghe-molaro commented Jan 29, 2026

Uh oh!

RachelMurray-Watson commented Jan 29, 2026

Uh oh!

RachelMurray-Watson commented Jan 29, 2026

Uh oh!

marghe-molaro commented Jan 29, 2026

Uh oh!

RachelMurray-Watson commented Apr 10, 2026

Uh oh!

marghe-molaro left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

RachelMurray-Watson commented Jan 29, 2026 •

edited

Loading