Variable cycle length

[jrdnmdhl]

It would be potentially useful to implement variable cycle length by treating cycle_length as a vector w/ same length as cycle.

Models w/ variable cycle length are occasionally useful when you have a very complex model (you can easily have hundreds of states due to tunnels) where precision is very important at some points but not others.

A typical use case would be for modeling curable diseases with complex health states. Early on, it is very important to precisely model transitions. Later on, this is less important because mortality is based life table data which is only available at annual intervals anyway.

This is probably a bit less important for heemod than excel, which is a good deal slower, but I think it may still be useful as a feature.

[pierucci]

Yeah I agree, I thought about that a while ago. I see no simple way of doing it in a general way.

As you said the only situation where this is really needed is caused by matrix evaluation performance issues with tunnel-state expansion (when state_time is used). Otherwise matrix evaluation is almost always not a bottleneck, whatever the number of cycles. And I see 2 solutions for that specific problem:

1. Limit state expansion.
2. Optimize transition matrix evaluation.

Solution 1 is already partly implemented with the state_time_limit of run_model(). It just keeps values with state-time dependency constant after a given time, and thus limits the number of tunnel states.

I think it could be developed to allow for a finer control over some kind of state-time "discretization", e.g. after 10 cycles we create only a new tunnel state every 5 cycles (thus keeping the time-dependent values constant for 5 cycles), then after 50 cycles creating a new tunnel state every 10 cycles, etc. This would result in an important reduction of the number of tunnel states leading to huge performance gains, at the cost of "down-sampling" values with state-time dependency.

Solution 2 is more ambition and addressed in #222.

[jrdnmdhl]

I think you are right that you can get enough performance gains elsewhere. This feature might also be useful matching existing models which use variable cycle lengths, but that's also probably not very important.

I think it could be developed to allow for a finer control over some kind of state-time "discretization", e.g. after 10 cycles we create only a new tunnel state every 5 cycles (thus keeping the time-dependent values constant for 5 cycles), then after 50 cycles creating a new tunnel state every 10 cycles, etc.

It would be helpful if you could expand on this. I'm not sure I've understood it correctly. Don't the tunnels have to be every cycle in order to keep track of time since entry? If the tunnels are every five cycles, how do you distinguish those who entered last cycle vs. five cycles ago?

[pierucci]

Don't the tunnels have to be every cycle in order to keep track of time since entry? If the tunnels are every five cycles, how do you distinguish those who entered last cycle vs. five cycles ago?

Oh dear! You are perfectly right, that doesn't work at all. That just confirms my brain shuts down on Fridays...

[pierucci]

It would be possible to add variable cycle length for models, but I don't see how to support models with state-time dependency.

1. cycles could be a vector of increasing integer values.
2. Most probabilities would need to be rescaled depending on the cycle length with rescale_prob().
3. The cycle length would be given by a cycle_length reserved variable, where cycle_length = diff(cycles).
4. An error is thrown if state time dependency is detected.

So you'd have to define all probabilities like that p_cycle = rescale_prob(p1, to = cycle_length).

But as you said except reproducing other models I don't really see the usefulness of that feature.