Source code accompanying 'Mathematics of Epidemics on Networks' by Kiss, Miller, and Simon http://www.springer.com/us/book/9783319508047 . Documentation for the software package is at https://epidemicsonnetworks.readthedocs.io/en/latest/
MIT License
151
stars
61
forks
source link
Create nonMarkovian arbitrary transitions function #26
This would be structured similarly to Gillespie_Arbitrary, but the input graphs' edge weights would be functions.
The thing that makes this difficult is how to handle say an SIS like case where an infected neighbor of an I node recovers. In the existing SIS code, there is a list saved of those transitions. That may be complicated here.
My current thought is that when a node u enters a state 'X', we check for when u would leave X on its own and for each partner v create a list of all times it might try to alter v's status (considering all possible statuses v might ever have -see below 1) . Then store that list with an event set for the first time. When that event happens, we should double check that u hasn't had its status altered in the interim (easiest way I can think to do this is have a counter for u that increments when it changes status). If u's status has altered then we don't requeue these events; otherwise, once we process the event we requeue the future events.
1) It may be worth creating a graph that finds all possible transitions, and then for each possible state, creating a set of possible future states. this would allow us to avoid some calculation of u acting on v if we can be sure v will never have some status in the future.
This would be structured similarly to Gillespie_Arbitrary, but the input graphs' edge weights would be functions.
The thing that makes this difficult is how to handle say an SIS like case where an infected neighbor of an I node recovers. In the existing SIS code, there is a list saved of those transitions. That may be complicated here.
My current thought is that when a node u enters a state 'X', we check for when u would leave X on its own and for each partner v create a list of all times it might try to alter v's status (considering all possible statuses v might ever have -see below 1) . Then store that list with an event set for the first time. When that event happens, we should double check that u hasn't had its status altered in the interim (easiest way I can think to do this is have a counter for u that increments when it changes status). If u's status has altered then we don't requeue these events; otherwise, once we process the event we requeue the future events.
1) It may be worth creating a graph that finds all possible transitions, and then for each possible state, creating a set of possible future states. this would allow us to avoid some calculation of u acting on v if we can be sure v will never have some status in the future.