You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The attached zip files contains an example for reproducing the error and for how it was worked around.
campaign_orig.json is the original JSON.
campaign_Dan.json is the workaround
Look at the stdout.txt to get the version hash to work with these input files
Executive Summary
ControlledVaccine (and SimpleVacine) while using WaningEffectMapPiecewise (and linear) expire (removed from person) TWO timesteps after the end of the Durability_Map. When it does expire, the efficacy as determine by the WaningEffect is still applied right before the intervention is removed from the person. This means a report counting people during that time step with the intervention will not count that person even though they might have efficacy.
Use Case Where Issue Was Found
Scenario Description
A user was playing around with the distribution of PrEP (via ControlledVaccine) and she was seeing some weird things. She wanted to distribute PrEP once per year to everyone who did not have HIV. She then want PrEP to last one year, so at the beginning of the next year, she could redistribute PrEP to HIV negative people. She was targeting people 15-50. Since she was playing around she wanted efficacy to 1.0 during that year.
Explanation to the user about what was found and how to solve it
First, the age values in Report_HIV_ByAgeAndGender_Collect_Age_Bins_Data array are the minimum age of the bin. I confused myself and thought they were the max.
The first change you will need to make to your code is to use the change the duration of your PrEP to be the following:
"Times": [ 0, 334, 335 ], "Values": [ 1, 1, 0 ]
Then next thing to change is Duration_To_Wait_Before_Revaccination = 364
There is a bug where ControlledVaccine lasts one extra time step. That is, you specified 365, but it didn't expire until 365 + one timestep. After I changed Report_HIV_Period from 730 to 60.8, I could see the data for each time step and saw the following:
Since the interventions were still there when the we were trying to distribute the next set of vaccines, the Duration_To_Wait_Before_Revaccination set to max float would keep the new intervention from being received by the individual and you were getting these gaps
Actually, it was expiring two timesteps (i.e. February of the next year instead at the end of December)
That might make you want to change 365 to 305, but then you get the issue is that the intervention expires in December (while giving the person protection), but it is removed from the individual so in the report you don't see that the person has the intervention in December.
Hence, I have the efficacy going through 334 which gets it through the end of December, but it the 335 with efficacy = 0, has the intervention last into January so that the person has the intervention in December. They start with in January but doesn't project the person.
to get the next set of vaccines to be distributed we need to set Duration_To_Wait_Before_Revaccination to 364 so that in January of the next year they will be accepted.
oh, you did have an issue where the day of your last campaign was 19711 instead of 19710. This caused another gap in coverage.
Now we get something like:
If we look at the front edge of coverage, 15-20, we see
We see it go down each year, but cause the people that got the intervention age out of the 15-20 and the people aging do not have the vaccine.
The 45-50 looks like you'd expect
If we look at the 50-55 bin, we see some behavior that makes sense and some that is due to trying to make the intervention be in the person in December
You see the lines go up say from the beginning of the first hill to the peak, because of people aging from the 45-50 bin into the 50-55 bin. This part makes sense.
I have not verified this, but I believe that it doesn't go to zero because of when StandardEventCoordinator (SEC) distributes the interventions versus when the age of the people are updated. That is, SEC distributes the intervention at the beginning of the timestep BEFORE people have aged so the people who are 49.99 will get the new intervention and move to the 50-55 bin when they are updated.
The text was updated successfully, but these errors were encountered:
4d26386b-a3aa-4703-b3a9-d0c9b82ab011.zip
The attached zip files contains an example for reproducing the error and for how it was worked around.
Executive Summary
ControlledVaccine (and SimpleVacine) while using WaningEffectMapPiecewise (and linear) expire (removed from person) TWO timesteps after the end of the Durability_Map. When it does expire, the efficacy as determine by the WaningEffect is still applied right before the intervention is removed from the person. This means a report counting people during that time step with the intervention will not count that person even though they might have efficacy.
Use Case Where Issue Was Found
Scenario Description
A user was playing around with the distribution of PrEP (via ControlledVaccine) and she was seeing some weird things. She wanted to distribute PrEP once per year to everyone who did not have HIV. She then want PrEP to last one year, so at the beginning of the next year, she could redistribute PrEP to HIV negative people. She was targeting people 15-50. Since she was playing around she wanted efficacy to 1.0 during that year.
Explanation to the user about what was found and how to solve it
First, the age values in Report_HIV_ByAgeAndGender_Collect_Age_Bins_Data array are the minimum age of the bin. I confused myself and thought they were the max.
The first change you will need to make to your code is to use the change the duration of your PrEP to be the following:
"Times": [ 0, 334, 335 ], "Values": [ 1, 1, 0 ]
Then next thing to change is Duration_To_Wait_Before_Revaccination = 364
There is a bug where ControlledVaccine lasts one extra time step. That is, you specified 365, but it didn't expire until 365 + one timestep. After I changed Report_HIV_Period from 730 to 60.8, I could see the data for each time step and saw the following:
Since the interventions were still there when the we were trying to distribute the next set of vaccines, the Duration_To_Wait_Before_Revaccination set to max float would keep the new intervention from being received by the individual and you were getting these gaps
Actually, it was expiring two timesteps (i.e. February of the next year instead at the end of December)
That might make you want to change 365 to 305, but then you get the issue is that the intervention expires in December (while giving the person protection), but it is removed from the individual so in the report you don't see that the person has the intervention in December.
Hence, I have the efficacy going through 334 which gets it through the end of December, but it the 335 with efficacy = 0, has the intervention last into January so that the person has the intervention in December. They start with in January but doesn't project the person.
to get the next set of vaccines to be distributed we need to set Duration_To_Wait_Before_Revaccination to 364 so that in January of the next year they will be accepted.
oh, you did have an issue where the day of your last campaign was 19711 instead of 19710. This caused another gap in coverage.
Now we get something like:
If we look at the front edge of coverage, 15-20, we see
We see it go down each year, but cause the people that got the intervention age out of the 15-20 and the people aging do not have the vaccine.
The 45-50 looks like you'd expect
If we look at the 50-55 bin, we see some behavior that makes sense and some that is due to trying to make the intervention be in the person in December
You see the lines go up say from the beginning of the first hill to the peak, because of people aging from the 45-50 bin into the 50-55 bin. This part makes sense.
I have not verified this, but I believe that it doesn't go to zero because of when StandardEventCoordinator (SEC) distributes the interventions versus when the age of the people are updated. That is, SEC distributes the intervention at the beginning of the timestep BEFORE people have aged so the people who are 49.99 will get the new intervention and move to the 50-55 bin when they are updated.
The text was updated successfully, but these errors were encountered: