dic.fit.mcmc: Switch likelihood to primarycensored

[seabbs]

I was just looking through this to see what can be done about serial interval estimation in EpiEstim not supporting right truncation adjustment (which I think is somewhat critical given the user base and common usage imo) mrc-ide/EpiEstim#186. It looks like one option could be to modify dic.fit and dic.fit.mcmc to use the R side likelihoods from primarycensored (https://primarycensored.epinowcast.org/reference/dprimarycensored.html) this would give you many more distributions and both upper and lower bound truncation support.

One complexity is that package achieves its flexibility by modelling the intervals as a primary (hence the name) and secondary event interval - the maths shows this shakes out to the same thing but it means the inputs differ. I haven't looked in detail at your interface so perhaps that isn't an issue.

I can imagine that you might not want to make significant changes to this package as it will drift it from the target paper which is fair enough. In that case I think it would be great to consider adding some warnings about settings where the current functionality will give misleading results (i.e. outbreaks).

[nickreich]

If I understand the issue correctly, you are saying that the approach we use in coarseDataTools does not make adjustments to account for a setting where there is a set of observations that are not representative of the full population. So for example in the beginning of an outbreak's growth phase when you presumably are missing many of the longer incubation periods, if you use the base functionality in coarseDataTools you would get a biased estimate of the incubation period or serial interval distribution because it doesn't know how to make likelihood adjustments for not seeing the missing ("right truncated") observations.

I agree that this is an unaddressed issue in the package. I'm not actively developing the package anymore (other than to fix major bugs or maintain presence on CRAN) but I'd welcome PRs that might address this issue, either through just delivering warnings or through a deeper re-working of the guts of the likelihoods.

[seabbs]

Hi @nickreich,

Yes exactly.

Yes totally fair enough - that was my assumption. I might do a staged approach with one a documentation PR and then we can see how that feels. If it feels like more would be useful here happy to help out adding that but I think might be tricky without substantial refactoring which I am not sure would really benefit the package which already has quite a clear use case and good adoption etc.