-
Notifications
You must be signed in to change notification settings - Fork 6
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
Incorporate cadre allocation computations more into mainline #259
Conversation
The cadres_ sheets are reformatted to introduce two-level headers (issue #244). This is a breaking change, affecting 1) how overhead hours are calculated and 2) post-processing cadre allocation.
…ion: PaceInitialize()
…unit test coverage.
* add cadre sheet header validation * update validation rules based on discussion * fix rule 5 and description * add rule 6 and cadre plot for more information * fix plyr issue * add namespace * fix type problem
@MeWu-IDM : Integration tests are failing, but I don't understand why. Over to you! Update: Working now after merging input format changes from 244 into 51. |
does pacehrh:::SaveCadreAllocations not work with the results from pacehrh::ReadAndCollateSuiteResults after this change? |
@celiot-IDM, is RoleID required to be unique for task time allocation to cadre to compute correctly? |
…aseModeling/Ethiopia-HEP-Capacity-Analysis into demo_regression_testing
add dplyr:: to mutate and summarise
…eforDiseaseModeling/PACE-HRH into demo_regression_testing
The overhead times calculation will work just fine with duplicate RoleID values. After that it's up to you (the researcher) to collate RoleID's with the role information embedded in the headers of the cadre task sheets. |
Set rounding = "Late" to match Run_simulations
Delete: Run_simulations_new.R and model_inputs_shiny_demo.xlsx were used for testing purposes only. Update: Run_simulations.R, model_inputs_demo.xlsx Add: Analysis_pipeline_demo.R
Add dply:: to summarise, mutate and arrange
…ion_testing Demo regression testing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We were able to update the scripts to produce the same cadre allocation results (Run_simulation.R is updated)
Regression tests are also updated to cover the new cadre calculation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Run_simulations.R is updated to post-process new cadre allocations results structure. Model_inputs_demo.xlsx is updated to new structure and we were able to use these inputs to confirm the calculation results match the old results.
Phew ... this work started out with a small idea and turned into something very big.
The core work takes the cadre allocation computations that used to be done by functions in pace_post_process.R and moves them more into the mainline of process. So instead of using suite results CSV files as inputs, post-processing information can now be done immediately after an experiment finishes, based on the
results
structure returned byRunExperiments()
.NOTE: THIS IS A BREAKING CHANGE. Old versions of the post-processing code won't work with the new Cadre allocation sheet format. A side-effect of making cadre roles user-configurable at the scenario/delivery-model level is that we can't naively combine suite result CSV files the way it was done before by
ReadAndCollateSuiteResults()
. (The key problem is that a user could configure a member ID - e.g "HEW1" - to mean one thing in one delivery model, but something different in another delivery model. Different delivery models have different cadre memberships - MergedModel = {HEW1 | HEW2 | FHP1 | FHP2}, but BasicModel = {HEW1 | HEW2 | FHP1 | FHP2 | RN | EHP} - so it's possible that in trying to create one big view that crosses several delivery models, we could end up aggregating things that shouldn't be aggregated.)Annual overheads are calculated for all cadre members in all models, but I'm not sure how you want to access that information.
Here's a sample of the new approach.
Two additional bits of magic ...
Magic 1: If you don't need to keep the output from
SaveExtendedSuiteResults()
(basically a much wider version of the standard output, but extended with Scenario and Task information), you can speed things up a bit by piping:Magic 2: Both
SaveExtendedSuiteResults()
andSaveCadreAllocations()
take filepath parameters which will save their outputs to disk.I have some more tidying up to do, but I'm going to move on to finish off the stochastic rate capping work now.
Addresses #51