Bias in my SIS model - bad math or model bug?

[KevinMcCarthyAtIDM]

In building up my generic models and tests on them, I'm getting some slight differences in my SIS model relative to what I expect, and want to note here so we dig deeper into this.

Essentially, I believe that outputs of my SIS model, without demography:

should follow the logistic growth equation:

I do observe logistic growth, but at higher values of gamma, when I fit the equation to the output, I consistently get a gamma that's biased slightly high - or that is, the fit finds a model infectious duration shorter than I expect.

The below shows a random simulation - actual simulation output in blue, fitted output in dashed orange, and logistic equation output with the exact model inputs in orange.

So the blue curve ends up at a final infected fraction below what's expected from the logistic equation. The fit, with higher gamma, does a great job fitting the output. And the bias makes sense - the tradeoff between beta and gamma sets the final infected fraction, with longer infectious periods meaning more people infected at equilibrium, and the fit does produce something with shorter average infectious period to get that smaller equilibrium infected fraction..

Anyway, it's entirely plausible I messed up the math a little bit, need to check on that. But if not, this is a thread worth tugging at.

[KevinMcCarthyAtIDM]

The math appears to be good.

Part of the issue appears to be related to the choice of distribution for itimer. Switching to a fixed value for itimer gets me a lot closer than using an exponential distribution - I had expected the exponential distribution to be a closer approximation to what is actually going on in the compartmental version. Something to come back to

[KevinMcCarthyAtIDM]

LOL pretty darn sure this is because I'm overflowing the range of uint8 for the itimer. Using exponential distribution with means up to 100, where a substantial number of draws will be >255. The fits are solid at low mean, start to be biased downward as the mean goes up. Pretty sure this is it. Fits all look good if I cap the mean infectious period at 40, where 99.9% of values should be <=255.
I suppose the nail in this would be to move that up to a uint16 and see whether the effect disappears. But it's Friday night, calling it.

[KevinMcCarthyAtIDM]

Confirmed that the error is due to overflow of the uint8 datatype for itimer with the distribution and parameter values I had chosen for my tests. Changed datatype to uint16 and now get a good fits at the longer itimer periods that were giving me trouble before - below is an example with itimer exponentially distributed with mean 280.

For now - I will revert the changes and keep this a uint8, and reduce the range of values I'm using in this test.

[KevinMcCarthyAtIDM]

Close, as not technically a "bug". Superseded by #11 - should we have better checking/warning when we overflow a uint datatype?