| Summary: | values in Incidence_2.csv file don't match with S to E transition calculations | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] STEM | Reporter: | Traci Arthur-Hartranft <traci.arthur-hartranft> | ||||
| Component: | Analysis | Assignee: | Stefan Edlund <sedlund> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | sedlund | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 1.1.2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Assigning to me. The source of the bug is known, will discuss with Jamie when he returns Monday. Incidence is now calculated correctly by summing for each step calculated by integration and resetting the value at the beginning of a new timestep. Previous code was simply doing a finite difference estimation. Complete |
Created attachment 177558 [details] spreadsheet showing example results; yellow columns are copied from STEM .csv files, others were calculated; red text was expected to match more closely This is based on a simple case of a DeterministicSEIRDisease model where there are no changes in population (natural birth and death rate=0), no disease deaths (infectious mortality rate=0) and no movement from R back to S (immunity loss rate=0). Incidence is stated to be the transition from S to E in a time step. Given the simple example above, movement from S to E should be constrained to be equal to the reduction in S between time steps. But the calculated S to E values can be off by up to 1000 or so from the Incidence file results. A summary is in the attached spreadsheet for a single county where I started with 200 infected people.