stewid / SimInf

A framework for data-driven stochastic disease spread simulations
http://stewid.github.io/SimInf/
GNU General Public License v3.0
33 stars 14 forks source link

extTrans non-sequential alternative? #50

Open loganwur opened 9 months ago

loganwur commented 9 months ago

Dear authors,

I'm using SimInf to model transmission between an insect vector and two livestock host species. The insect vector is susceptible to being blown around by the wind so I'd like to use extTrans events to move them between nodes, which represent grid cells on a surface. However, the extTrans events do not work, because they are processed sequentially and order matters. For example, after moving 50% of the vector population from node 1 to node 2, an external transfer sampling from node 2 will include the vector population just transferred from node 1 in the sampling. This is undesirable behavior for this scenario. Am I missing something in the documentation that would allow for multiple extTrans events to be processed before laying down the resulting vector population distribution over the grid? If not, this would be a very handy functionality for vector or particle dispersion over a gridded surface.

Cheers,

Logan

trosendal commented 9 months ago

This is also considered in this https://github.com/KSTuominen/LAMRSAControl. In that repo we solve the same problem by scaling the events in the order they will be applied to give the result you desire:

https://github.com/KSTuominen/LAMRSAControl/blob/41da04ad74d27eeed1f6231999e55052236c9162/R/events.R#L176

You can see an example of how the resultant events are rescaled here:

https://github.com/KSTuominen/LAMRSAControl/blob/master/tests/scaled_p.R

As you alluded to the order of the processing of events is critical to understand this: They are processed after the Gillespie part of the model and in the order: time, id of origin node, id of destination node.

loganwur commented 9 months ago

Thanks again @trosendal. I'll look into this. Glad I don't have to re-invent the wheel. If I can implement this, then I won't have to calculate and insert bunches of exit and enter events between time-points 'pausing' the model at each and every time-step, as was my initial idea for a work-around. I'll have a look.