Hey everyone, we are having a rather spontaneous epinowcast meeting tomorrow morning!
Everyone is welcome to join. Please find a zoom link below.
Sep 30, 2022: 9:30 AM UK Time / 10:30 AM CEST
https://ethz.zoom.us/j/65369558932
Meeting ID: 653 6955 8932
I’m in! Lots of cool stuff happening on here to touch on.
I’m interested in joining these meetings but that’ll be 4:30AM for me (New Jersey, US)… it would be nice if future meetings could be held later if it’s not inconvenient for other people.
And 4.30am is a bit early for you? I’ve usually done an hour of meditation by then 
No totally agree this isn’t ideal.
This meeting really just a last minute thing as we missed last weeks due to the person who was meant to be organising (me) being ill and not doing so.
In the future will make sure we pick a better time and advertise with more notice.
Historically this has been the third Thursday of each month at 1pm gmt which might still be a bit early?Perhaps we should run a poll to pick a better time/date combination.
It’s 1:30am my time…later would be great.
Note: some people that were interested in joining this rather spontaneous meeting could not participate because of a different time zone. In the future, we will try to arrange meeting times that are as compatible with everyones sleeping patterns as possible 
We follow a general rule: During meetings, no final decisions regarding the development of epinowcast or the community are made. Actual decisions/consensus should always be established in text form on the discourse forum. Of course this will not always be 100% enforced, e.g. regarding very small implementation decisions for a single feature when everyone involved was on the call. But especially if decisions have implication for epinowcast as a whole or could be of interest the the wider community, we try to stick to this rule.
Of course we will make plans during a meeting and get a consensus of the people on the call. But we should at least always describe the plans on the minutes from the meeting and give other people the chance to comment/veto before carrying them out.
The forecasting post this was based on can be seen here: Forecasting in epinowcast - #4 by Gunnar
@Gunnar has implemented a neat approach to extend the current expectation model to forecasting (by projecting it beyond the present for a certain forecasting horizon, using the generated quantities).
There are several levels of extension of this approach which could make sense to have
The PR this discussion was based on can be seen here: Flexible expectation model by seabbs · Pull Request #152 · epinowcast/epinowcast · GitHub
There was a discussion about the use of modifiers to the expected observations in the expectation model. The general idea is to allow for seasonality/differences etc. in the observations by reference date, e.g. when people are more/less likely to get tested on a certain day of the week.
The current state in the expectation model PR is to apply a modifier to the expected observations after they have been computed from the latent cases using the latent delay distribution. Part of this was to enforce that the modifier model has an intercept of zero. In the meeting, we came to the conclusion that it is conceptually more appealing to apply the modifier rather to the latent delay distribution and then compute the expected observations afterwards.
This doesn’t make a difference to the model really, but makes the modifier more similar to the reporting day effects in the reporting delay model, which makes sense conceptually. In fact, the long-term goal would be to express the latent delay distribution (and also the generation time distribution) also via a discrete-time survival model. The modifier would then be on the hazard scale.
A different aspect is an overall scaling of latent cases to observations, e.g. scaling from infections to observed deaths using an infection-fatality-rate (IFR). This is something that will probably only be possible using a very strong prior and/or several data streams (e.g. cases and deaths). Currently, it is implicitly supported by the possibility to supply an improper (i.e. scaled) latent delay distribution (see test script Germany_latent_renewal.R on that branch). We said the we want to leave this for now as is and add a scaling component/submodule at a later stage maybe.
Finally, there was a short discussion regarding the log scale modeling of the renewal process and potential tradeoffs with modeling a stochastic renewal equation (implementing a sampling of infections on the log scale may prove difficult). Before going more into this, we however have to figure out whether log scale modeling actually works efficiently for the renewal process. Some people (me) still have doubts about it 
We are thinking of adding additional packages, e.g. for a baseline nowcasting model (Include a simple reference model - #6 by samabbott) that does not require stan to run, or for loading nowcasting datasets (Create a collection of benchmark data sets - #4 by samabbott, both nice ideas by @johannes ) to the epinowcast github organization - instead of adding these things to the main epinowcast package itself.
In the long run, we might also separate the pre- and postprocessing functionality from the nowcasting model, allowing more modularity. The separated packages will of course depend on each other to a certain extent.
Please let us know if you have thoughts on this.