forked from mrc-ide/malariasimulation
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bitset index2 everywhere #12
Closed
Closed
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
…(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
…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.
…ps://github.com/mrc-ide/malariasimulation into competing_hazards_recovery_infection_resolution Rebased using dev.
… (e.g., n_age... rather than n_...)
This reverts commit 5fec286.
We only need to perform the selection for individuals that passed the occurs check, not the entire population.
…very_infection_resolution
Eventually this should go into individual.
/benchmark |
This is how benchmark results would change (along with a 95% confidence interval in relative change) if b3d06db is merged into dev:
Further explanation regarding interpretation and methodology can be found in the documentation. |
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.
No description provided.