Competing hazards recovery infection resolution #300

RJSheppard · 2024-05-02T16:01:53Z

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!

…(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.

…(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

giovannic

This is a massive change. Thank you so much for the effort, it has been really thorough.

Few changes for readability and performance

giovannic · 2024-05-30T14:02:33Z

R/disease_progression.R

+  if(isFALSE(parameters$antimalarial_resistance) & length(dt_input) == 1 & is.numeric(dt_input)){
+    dt_v <- dt_input
+  } else if (isTRUE(parameters$antimalarial_resistance)) {
+    dt_v <- dt_input$get_values(variables$state$get_index_of("Tr"))
+  }


We probably want to cover all cases and use boolean instead of bitwise operators.

Suggested change

if(isFALSE(parameters$antimalarial_resistance) & length(dt_input) == 1 & is.numeric(dt_input)){

dt_v <- dt_input

} else if (isTRUE(parameters$antimalarial_resistance)) {

dt_v <- dt_input$get_values(variables$state$get_index_of("Tr"))

}

if(isFALSE(parameters$antimalarial_resistance)){

stopifnot(length(dt_input) == 1 && is.numeric(dt_input)) # please move this check to pre-simulation time for efficiency

dt_v <- dt_input

} else {

dt_v <- dt_input$get_values(variables$state$get_index_of("Tr"))

}

I've made this change.

giovannic · 2024-05-30T14:13:27Z

R/disease_progression.R

+  recovery_rates <- numeric(length = parameters$human_population)
+  recovery_rates[variables$state$get_index_of("D")$to_vector()] <- 1/parameters$dd
+  recovery_rates[variables$state$get_index_of("A")$to_vector()] <- 1/parameters$da
+  recovery_rates[variables$state$get_index_of("U")$to_vector()] <- 1/parameters$du
+  recovery_rates[variables$state$get_index_of("Tr")$to_vector()] <- 1/dt_v
+  recovery_outcome$set_rates(recovery_rates)


It's perhaps more efficient to create and update a new variable called recovery_rates in the progression processes. Then all of this becomes.

Suggested change

recovery_rates <- numeric(length = parameters$human_population)

recovery_rates[variables$state$get_index_of("D")$to_vector()] <- 1/parameters$dd

recovery_rates[variables$state$get_index_of("A")$to_vector()] <- 1/parameters$da

recovery_rates[variables$state$get_index_of("U")$to_vector()] <- 1/parameters$du

recovery_rates[variables$state$get_index_of("Tr")$to_vector()] <- 1/dt_v

recovery_outcome$set_rates(recovery_rates)

recovery_outcome$set_rates(variables$recovery_rates$get_values())

I think this actually tidies up some of the issues I was having integrating with @tbreweric 's dt variable. I'm guessing that if we're storing all the recovery rates as a variable then we can replace the dt variable with a recovery_rates variable and still store all the relevant information. Let me know what you think with what I've done.

giovannic · 2024-05-30T14:18:20Z

R/competing_hazards.R

+    stash_source_humans = function(source_humans){
+      self$source_humans <- source_humans
+    },


We don't need this anymore? It's ugly 😆

Suggested change

stash_source_humans = function(source_humans){

self$source_humans <- source_humans

},

Yep - gone!

giovannic · 2024-05-30T14:20:30Z

R/human_infection.R

-#' Updates human states and variables to represent asymptomatic/clinical/severe
-#' and treated malaria; and resulting boosts in immunity
+#' This function ends with the assignment of rates of infection to the competing
+#' hazard resolution object.  Boosts immunity given infectious bites.


Suggested change

#' hazard resolution object. Boosts immunity given infectious bites.

#' hazard resolution object and boosts immunity given infectious bites.

Made this change.

giovannic · 2024-05-30T14:20:52Z

R/human_infection.R

  source_humans <- variables$state$get_index_of(
    c('S', 'A', 'U'))$and(bitten_humans)
+  infection_outcome$stash_source_humans(source_humans)


Suggested change

infection_outcome$stash_source_humans(source_humans)

giovannic · 2024-05-30T14:28:31Z

R/processes.R

+
+  infection_outcome <- CompetingOutcome$new(
+    targeted_process = function(timestep, target){
+      infection_process_resolved_hazard(timestep, target, infection_outcome$source_humans,


Suggested change

infection_process_resolved_hazard(timestep, target, infection_outcome$source_humans,

infection_outcome_process(timestep, target,

giovannic · 2024-05-30T14:28:52Z

R/processes.R

+
+  recovery_outcome <- CompetingOutcome$new(
+    targeted_process = function(timestep, target){
+      recovery_process_resolved_hazard(timestep, target, variables, parameters, renderer)


Suggested change

recovery_process_resolved_hazard(timestep, target, variables, parameters, renderer)

recovery_outcome_process(timestep, target, variables, parameters, renderer)

giovannic · 2024-05-30T14:32:56Z

R/processes.R

+  create_infection_rates_process <- function(timestep){
+    biting_process(


couldn't we keep the function factory in biting_process.R?

In this file we've been calling function factories from *_process.R files. But now we're making the functions in processes.R. It feels a bit inconsistent. And verbose since we have a lot of processes to create.

I agree - I found this a little confusing to follow

I think I understand what you're saying, and I've had a go at implementing this.

giovannic · 2024-05-30T14:38:24Z

R/processes.R

+  # Disease Progression
+  # ===================
+
+  create_recovery_rates_process <- function(timestep){


Again, making the function here when it could be in disease_progression.R

giovannic · 2024-05-30T14:51:22Z

R/human_infection.R

+infection_process_resolved_hazard <- function(
+    timestep,
+    infected_humans,
+    source_humans,


This is not used

Suggested change

source_humans,

giovannic · 2024-06-03T10:03:02Z

Also if you could rebase with dev, then we can run benchmarks to get an idea of the performance tradeoff.

pwinskill

Thanks @RJSheppard. Some additional comments from me.

I was looking at the plots you submitted with the initial PR. Are these still valid now? The increase in prevalence for mid-EIRs was quite marked (if I was interpreting the plots correctly), which I think we should check and be cautious about.

I think, if those changes are that apparent we should probably look at PfPr~EIR plot similar to that in Penny et al. If possible lines for current and after changes would be helpful.

pwinskill · 2024-06-03T10:37:48Z

R/human_infection.R

+  )
+
+  ## capture infection rates to resolve in competing hazards
+  infection_rates <- numeric(length = parameters$human_population)


Would the following make it more clear that rates that are not overwritten in the following line are 0?

Suggested change

infection_rates <- numeric(length = parameters$human_population)

infection_rates <- rep(0, length = parameters$human_population)

pwinskill · 2024-06-03T10:44:02Z

R/processes.R

+  create_infection_rates_process <- function(timestep){
+    biting_process(


I agree - I found this a little confusing to follow

pwinskill · 2024-06-03T10:45:00Z

R/render.R

+#' @param timestep current target
+#' 
+#' @noRd
+incidence_probability_renderer <- function(


Maybe not for this PR - but does anyone use these probability of incidence outputs?

Whenever I look at this it always takes me a few to work out what it even means. I'd be happy to remove it, but agree it would be good to check if anyone uses it.

These are a smoother version of the incidence outputs, these should be closer to what Griffin's model outputs.

It seems unclear to me which, if any, should be removed

pwinskill · 2024-06-03T10:51:14Z

R/render.R

+    unique_age_combinations <- as.data.frame(unique(rbind(cbind(parameters$prevalence_rendering_min_ages, parameters$prevalence_rendering_max_ages),
+          cbind(parameters$incidence_rendering_min_ages, parameters$incidence_rendering_max_ages),
+          cbind(parameters$clinical_incidence_rendering_min_ages, parameters$clinical_incidence_rendering_max_ages),
+          cbind(parameters$severe_incidence_rendering_min_ages, parameters$severe_incidence_rendering_max_ages),
+          cbind(parameters$age_group_rendering_min_ages, parameters$age_group_rendering_max_ages))))
+
+    ordered_unique_age_combinations <- unique_age_combinations[
+      with(unique_age_combinations, order(V1, V2)),
+    ]


Suggestion for clarity (untested)

Suggested change

unique_age_combinations <- as.data.frame(unique(rbind(cbind(parameters$prevalence_rendering_min_ages, parameters$prevalence_rendering_max_ages),

cbind(parameters$incidence_rendering_min_ages, parameters$incidence_rendering_max_ages),

cbind(parameters$clinical_incidence_rendering_min_ages, parameters$clinical_incidence_rendering_max_ages),

cbind(parameters$severe_incidence_rendering_min_ages, parameters$severe_incidence_rendering_max_ages),

cbind(parameters$age_group_rendering_min_ages, parameters$age_group_rendering_max_ages))))

ordered_unique_age_combinations <- unique_age_combinations[

with(unique_age_combinations, order(V1, V2)),

]

age_ranges <- rbind(

cbind(parameters$prevalence_rendering_min_ages, parameters$prevalence_rendering_max_ages),

cbind(parameters$incidence_rendering_min_ages, parameters$incidence_rendering_max_ages),

cbind(parameters$clinical_incidence_rendering_min_ages, parameters$clinical_incidence_rendering_max_ages),

cbind(parameters$severe_incidence_rendering_min_ages, parameters$severe_incidence_rendering_max_ages),

cbind(parameters$age_group_rendering_min_ages, parameters$age_group_rendering_max_ages)

)

unique_age_combinations <- as.data.frame(unique(age_ranges))

ordered_unique_age_combinations <- unique_age_combinations[order(unique_age_combinations$V1, unique_age_combinations$V2), ]

Added this now - all seems to be working.

pwinskill · 2024-06-03T10:53:32Z

R/render.R

-    for (i in seq_along(parameters$age_group_rendering_min_ages)) {
-      lower <- parameters$age_group_rendering_min_ages[[i]]
-      upper <- parameters$age_group_rendering_max_ages[[i]]
+


@giovannic As these unique combinations of age ranges will not change throughout the simulation can we calculate them once when create_age_group_renderer() is called and not everytime when age_group_renderer() is called?

Yes! I thought I commented this, but that's gone missing. Good catch

I'm not sure I fully understand this. Is it as simple as moving the not repeating parts outside of the time looping section? The actual age rendering needs to occur at each time step, but the age rendering groups only need to be assigned once. I think I've done this now, but please let me know if it isn't what you meant!

pwinskill · 2024-06-03T10:54:39Z

R/utils.R

+#'@param rate rate
+#'@noRd
+rate_to_prob <- function(rate){
+  1- exp(-rate)


Suggested change

1- exp(-rate)

1 - exp(-rate)

RJSheppard · 2024-06-24T14:58:30Z

@pwinskill I'll rebase and make some plots as requested.

…now occurs in biting_process.R. Similarly, create_recovery_rates_process functionality is now in disease_progression.R stash_source_humans in competing hazard resolution is now redundant and has been removed from infection processes. recovery rates are now assigned to a variable which is updated as infections, recoveries (via update_infection) and deaths occur. This also takes into account recovery time of treated due to slow parasite clearance and replaced the dt variable. I've also noticed (I think) that Tr->S and U->S recoveries can be done in a single step, so have attempted to combine these at risk of making the code more complicated! Added a metapopulation incidence rendering wrapper function for initialising multiple renderers. Rewrote create_age_group_renderer for clarity following feedback. Some tests have been adjusted to reflect these changes.

…(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. Rebasing

Corrected dt variables recovery rate assignment when antimalarial resistance is modelled.

…(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.

…now occurs in biting_process.R. Similarly, create_recovery_rates_process functionality is now in disease_progression.R stash_source_humans in competing hazard resolution is now redundant and has been removed from infection processes. recovery rates are now assigned to a variable which is updated as infections, recoveries (via update_infection) and deaths occur. This also takes into account recovery time of treated due to slow parasite clearance and replaced the dt variable. I've also noticed (I think) that Tr->S and U->S recoveries can be done in a single step, so have attempted to combine these at risk of making the code more complicated! Added a metapopulation incidence rendering wrapper function for initialising multiple renderers. Rewrote create_age_group_renderer for clarity following feedback. Some tests have been adjusted to reflect these changes.

github-actions · 2024-07-04T11:29:32Z

This is how benchmark results would change (along with a 95% confidence interval in relative change) if 09e6e8c is merged into dev:

❗🐌large_population: 2.08m -> 3.58m [+69.96%, +73.6%]
❗🐌small_population: 32s -> 37.9s [+16.93%, +19.74%]

Further explanation regarding interpretation and methodology can be found in the documentation.
Plots and raw data are available as artifacts of the workflow run.

We only need to perform the selection for individuals that passed the occurs check, not the entire population.

plietar · 2024-07-04T13:09:16Z

/benchmark

plietar · 2024-07-04T13:39:57Z

/benchmark

github-actions · 2024-07-04T14:48:26Z

This is how benchmark results would change (along with a 95% confidence interval in relative change) if 1f7310b is merged into dev:

❗🐌large_population: 2.09m -> 2.9m [+36.48%, +40.88%]
❗🐌small_population: 32.5s -> 34.4s [+4.32%, +7.76%]

Further explanation regarding interpretation and methodology can be found in the documentation.
Plots and raw data are available as artifacts of the workflow run.

plietar

I might try to get those missing 40% back later but it doesn't seem worth blocking merging this anymore.

plietar · 2024-07-10T13:49:11Z

/benchmark

plietar · 2024-07-10T14:08:51Z

/benchmark

…very_infection_resolution

github-actions · 2024-07-10T15:14:04Z

This is how benchmark results would change (along with a 95% confidence interval in relative change) if 0bd7c10 is merged into dev:

❗🐌large_population: 2.11m -> 2.55m [+19.32%, +21.91%]
✔️small_population: 32.6s -> 33s [-0.99%, +3.56%]

Further explanation regarding interpretation and methodology can be found in the documentation.
Plots and raw data are available as artifacts of the workflow run.

Eventually this should go into individual.

plietar · 2024-07-10T15:19:48Z

/benchmark

github-actions · 2024-07-10T16:23:24Z

This is how benchmark results would change (along with a 95% confidence interval in relative change) if ded6876 is merged into dev:

❗🐌large_population: 2.09m -> 2.41m [+14.04%, +16.35%]
✔️small_population: 32.7s -> 32.8s [-1.83%, +2.52%]

Further explanation regarding interpretation and methodology can be found in the documentation.
Plots and raw data are available as artifacts of the workflow run.

…very_infection_resolution

giovannic · 2024-08-13T14:15:04Z

Any news on this? Would like to merge this

plietar · 2024-08-13T15:25:34Z

All done from my end. There's not much more to be gained I think.

RJSheppard requested review from giovannic, pwinskill and tbreweric May 2, 2024 16:01

RJSheppard force-pushed the competing_hazards_recovery_infection_resolution branch 2 times, most recently from 6bf22cc to 903547a Compare May 8, 2024 10:25

RJSheppard force-pushed the competing_hazards_recovery_infection_resolution branch from 91d50f4 to b36be83 Compare May 9, 2024 11:16

RJSheppard and others added 9 commits May 9, 2024 16:11

Added a stash source_human function to the competing hazards function…

0e05f75

… for use in infection outcome.

Added a stash source_human function to the competing hazards function…

c8c3245

… for use in infection outcome.

Removed "age" from age outputs in tests and vignettes.

4820186

Corrected dt variables recovery rate assignment when antimalarial resistance is modelled.

Swap back to explicitly labelled age outputs.

d563f6e

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

Merge branch 'dev' into competing_hazards_recovery_infection_resolution

b8980c1

Removed missed merge commit line.

62791a2

Correcting rendering tests (merging error).

1b30562

giovannic requested changes May 30, 2024

View reviewed changes

giovannic mentioned this pull request May 30, 2024

Add GitHub workflow for continuous benchmarking. #304

Merged

pwinskill reviewed Jun 3, 2024

View reviewed changes

RJSheppard added 9 commits June 24, 2024 16:31

Added a stash source_human function to the competing hazards function…

7702e19

… for use in infection outcome.

Removed "age" from age outputs in tests and vignettes.

6a4311a

Corrected dt variables recovery rate assignment when antimalarial resistance is modelled.

Added a stash source_human function to the competing hazards function…

98c982f

… for use in infection outcome.

Removed missed merge commit line.

16d83d3

Optimize competing hazards.

a58e064

We only need to perform the selection for individuals that passed the occurs check, not the entire population.

Fix empty occurs case.

1f7310b

giovannic approved these changes Jul 5, 2024

View reviewed changes

plietar approved these changes Jul 5, 2024

View reviewed changes

plietar added 2 commits July 10, 2024 14:32

Simplify competing hazards as a single random draw.

e2242b2

Try to optimize competing hazards

4c98559

plietar force-pushed the competing_hazards_recovery_infection_resolution branch from 7a118d1 to 4c98559 Compare July 10, 2024 13:40

All all states but S to create_recovery_rates_process

0bd7c10

Merge remote-tracking branch 'origin/dev' into competing_hazards_reco…

91697ba

…very_infection_resolution

Add a bitset_at implementation that works with a logical index.

ded6876

Eventually this should go into individual.

Fix tests

8f9bcfc

plietar added 5 commits July 11, 2024 14:01

Fix more tests

f363b94

Add tests

b339b7a

Use new individual features

f2cacfb

Merge remote-tracking branch 'origin/dev' into competing_hazards_reco…

e1bc3c1

…very_infection_resolution

Fix output test

babc34b

RJSheppard merged commit 3e76ce8 into dev Aug 20, 2024
4 checks passed

RJSheppard deleted the competing_hazards_recovery_infection_resolution branch August 20, 2024 10:34

giovannic mentioned this pull request Sep 11, 2024

Dev #335

Merged

	stash_source_humans = function(source_humans){
	self$source_humans <- source_humans
	},

	#' hazard resolution object. Boosts immunity given infectious bites.
	#' hazard resolution object and boosts immunity given infectious bites.

	infection_process_resolved_hazard(timestep, target, infection_outcome$source_humans,
	infection_outcome_process(timestep, target,

	recovery_process_resolved_hazard(timestep, target, variables, parameters, renderer)
	recovery_outcome_process(timestep, target, variables, parameters, renderer)

		create_infection_rates_process <- function(timestep){
		biting_process(

	infection_rates <- numeric(length = parameters$human_population)
	infection_rates <- rep(0, length = parameters$human_population)

Competing hazards recovery infection resolution #300

Competing hazards recovery infection resolution #300

Conversation

RJSheppard commented May 2, 2024

giovannic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

giovannic May 30, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

giovannic commented Jun 3, 2024

pwinskill left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RJSheppard commented Jun 24, 2024

github-actions bot commented Jul 4, 2024

plietar commented Jul 4, 2024

plietar commented Jul 4, 2024

github-actions bot commented Jul 4, 2024

plietar left a comment

Choose a reason for hiding this comment

plietar commented Jul 10, 2024

plietar commented Jul 10, 2024

github-actions bot commented Jul 10, 2024

plietar commented Jul 10, 2024

github-actions bot commented Jul 10, 2024

giovannic commented Aug 13, 2024

plietar commented Aug 13, 2024

giovannic May 30, 2024 •

edited

Loading