At the moment, a full EpiAware problem requires three Turing models as input: a latent process, an epi model for infections and an observation model.
The latent process (with sample paths canonically referred to as Z_t in code) is used in the epi model, which is fine except if it triggers a naming collision with latent processes optionally called inside the obs model (see #188 ).
It would seem to me that it makes more sense in terms of standard code patterns to refacter epi models so that they can optionally call latent processes within themselves as per observation models (e.g. EpiObsModels.Ascertainment). This still requires consideration of naming collisions, ergo doesn't fix #188, but would seem to be a cleaner interface.
At the moment, a full
EpiAware
problem requires threeTuring
models as input: a latent process, an epi model for infections and an observation model.The latent process (with sample paths canonically referred to as
Z_t
in code) is used in the epi model, which is fine except if it triggers a naming collision with latent processes optionally called inside the obs model (see #188 ).It would seem to me that it makes more sense in terms of standard code patterns to refacter epi models so that they can optionally call latent processes within themselves as per observation models (e.g.
EpiObsModels.Ascertainment
). This still requires consideration of naming collisions, ergo doesn't fix #188, but would seem to be a cleaner interface.