Competing hazards recovery infection resolution #300
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RJSheppard
force-pushed
the
competing_hazards_recovery_infection_resolution
branch
2 times, most recently
from
6bf22cc
to
903547a
Compare
…(containing an outcome following resolution and rates that that outcome occurs for each individual in the population) and CompetingHazard (contains all CompetingOutcomes and process function to resolve hazards). processes.R: create_biting_process now replaced with create_infection_rates_process and biting_process, that uses essentially the same functional pathway, but which stops when the rates of infection are generated, storing them in the infection_outcome object within human_infection.R Similarly, disease_progression_process(es) are replaced with new functions: create_recovery_rates_process and calculate_recovery_rates, that get the recovery rates for each individual based on disease state. We then add these processes to the process list, including the resolution function create_infection_recovery_hazard_process$resolve. This process (create_infection_recovery_hazard_process) contains infection_outcome and recovery_outcome. infection_outcome calls infection_process_resolved_hazard, which follows the rest of the infection pathway functions: assigning new infections to different human states. Note that this requires probability of infection which gets used in the incidence renderer function. recovery_outcome also updates human states and infectivities. I've adjusted some of the tests to reflect the changes in functions required to generate results. Removed white space deletions.
RJSheppard
force-pushed
the
competing_hazards_recovery_infection_resolution
branch
from
91d50f4
to
b36be83
Compare
… for use in infection outcome.
…(containing an outcome following resolution and rates that that outcome occurs for each individual in the population) and CompetingHazard (contains all CompetingOutcomes and process function to resolve hazards). processes.R: create_biting_process now replaced with create_infection_rates_process and biting_process, that uses essentially the same functional pathway, but which stops when the rates of infection are generated, storing them in the infection_outcome object within human_infection.R Similarly, disease_progression_process(es) are replaced with new functions: create_recovery_rates_process and calculate_recovery_rates, that get the recovery rates for each individual based on disease state. We then add these processes to the process list, including the resolution function create_infection_recovery_hazard_process$resolve. This process (create_infection_recovery_hazard_process) contains infection_outcome and recovery_outcome. infection_outcome calls infection_process_resolved_hazard, which follows the rest of the infection pathway functions: assigning new infections to different human states. Note that this requires probability of infection which gets used in the incidence renderer function. recovery_outcome also updates human states and infectivities. I've adjusted some of the tests to reflect the changes in functions required to generate results. Removed white space deletions.
… for use in infection outcome.
…olution (any rendering in the infection outcome does not occur), I've split the incidence renderer into three functions: age rendering, n incidence rendering and p incidence rendering. This allows much more flexibility in when these are called in the code sequence. All age inputs are now consolidated and rendered in a single function. In addition, we intitate and populate these incidence columns with 0 when they are used.
Corrected dt variables recovery rate assignment when antimalarial resistance is modelled.
Merge branch 'competing_hazards_recovery_infection_resolution' of https://github.com/mrc-ide/malariasimulation into competing_hazards_recovery_infection_resolution # Conflicts: # R/disease_progression.R # R/human_infection.R
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR resolves the competing hazards of infection and recovery. Giovanni wrote code to generate two competing hazards objects: CompetingOutcome (in which a function describing what happens to individuals following competing hazard resolution and the rates that that outcome occurs) and CompetingHazard (which links to each of the CompetingOutcome objects that require resolution, and which contains the process function that resolves the competing hazards), found in competing_hazards.R
We first replace create_biting_process and create_progression_process(es) with create_infection_rates_process and create_recovery_rate_process.
Create_infection_rate_process uses the renamed “biting_rate” (which was previously: create_biting_rate_process) which continues as previously, passing through the infection outcome object, and now ends when the rates of infection are generated. Note that we are currently only resolving infections in SA and U compartments, NOT D or Tr (consistent with deterministic model). Note also that new infections are not rendered until after occurrence of resolution.
Similarly, all recovery/progression processes are now replaced with a single create_recovery_rates_process function, that uses calculate_recovery_rates, based on individual state rates of recovery.
The create_infection_recovery_hazard_process then uses the CompetingHazard object (to which each competing hazard outcome is assigned) to resolve competing hazards and determine which outcome occurs to which individuals.
The infection_outcome uses a new function: infection_process_resolved_hazard, which picks up from where we previously left off in the infection process, rendering incidence and assigning infections severities. Note that this function requires the infection rates to allow the incidence renderer to function.
The recovery_outcome then uses recovery_process_resolved_hazard, streamlining the progression functions into the relevant update functions. This function also passes in the dt variable for antimalarial resistance @tbreweric. (Hopefully it will still work!).
I ran simulations to compare the current default model (with mortality as the last process) with the resolved hazards. We do see something of an increase in incidence (which increases with EIR) and prevalence.
competing_hazards_mortality_process_position.pdf
competing_hazards_resolved_timesteps.pdf
Human states also see fewer susceptibles, and is possibly deviating from the equilibrium a little.
competing_hazards_resolved_states.pdf
competing_hazards_resolved_states_time.pdf
Acquired immunities seem to be increasing a bit through time - consistent with higher onward infection following higher overall prevalence, particularly at lower EIR (higher plots).
competing_hazards_resolved_immunity.pdf
I also checked through the expected infections and recoveries compared with the equilibrium solution, and found reasonable consistency, and resolution of the hazards. Let me know your thoughts!