Update EpiProblem to take a single tspan

[seabbs]

For what I think are legacy reasons EpiProblem takes a vector of length two for its tspan argument. This is currently very poorly documented but I think was done to deal with dimension mismatches in the data generating process. I think we have now fixed that internally and so this is no longer needed. @SamuelBrand1 are you using this somewhere?

[seabbs]

Looking through the pipeline code it looks like we are using it to index into the data but this seems to break the idea that EpiProblem is data independent?

[SamuelBrand1]

The original concept was to have EpiProblem as close to a DEProblem struct from SciML. The reason that uses a Tuple{Real,Real} is that you might want time inhomogeneous processes, and thats why we have it too.

[SamuelBrand1]

Looking through the pipeline code it looks like we are using it to index into the data but this seems to break the idea that EpiProblem is data independent?

Not really, the EpiProblem object is stand-alone with an independent variable t (as per typical in dynamical systems). In the pipeline we are making the simplifying assumptions that the first index of the data aligns with $t = 1$ but that is not necessary.

This is so typical in dynamical system modelling... I'd probably need a good reason to vary.

[seabbs]

The reason that uses a Tuple{Real,Real} is that you might want time inhomogeneous processes, and thats why we have it too.

can you explain this more? We don't use it at all in model construction so it seems a but superfluous

Not really, the EpiProblem

The EpiProblem object is literally used to index into the data. For example in the Mishra replication

[SamuelBrand1]

can you explain this more? We don't use it at all in model construction so it seems a but superfluous

We don't use it currently, but it allows for custom models with an explicit $t$ dependence to have meaning. Thats why it exists in ODEProblem so you can define a vector field function as (u,p,t) -> du. Otherwise, you'd be restricted to (u,p) -> du vector fields or ones where $t$ only has a shift-invariant meaning. These are still essentially dynamical systems models we are doing.

The EpiProblem object is literally used to index into the data. For example in the Mishra replication

I wouldn't characterise that as breaking the idea that the model is data independent because you can generate on EpiProblem, it fully defines its data-independent distribution including (potentially) time-inhomogeneous effects. It can also have a simple link to data to define its conditional distribution too.

[SamuelBrand1]

I guess I'd flip this around and ask what is the special case consideration in Epi modelling that means we should deviate from the normal standard in dynamical systems modelling?