MovementModels in epymorph's current design can't know how many individuals are present in each geo node at some time in the middle of the simulation. This limitation is fine for many movement models, but a hindrance for others, so we can improve this.
Current behavior
Movement clauses are simply functions which calculate, for a particular simulation step (tick), the "requested" movement vector between all locations (an NxN matrix). The internal movement processing logic then uses this to compute the "actual" movement (an NxNxC matrix) by randomly selecting available individuals (each of which is, at that time, grouped into one of the IPM's compartments). It's not a problem for the MovementModel to request more movement than can be fulfilled by available individuals -- the logic handles capping movement appropriately.
For typical human commuter style movement, the number of individuals currently at each location is not very important information. The number of movers is usually much smaller than the non-moving population, and movers return fairly quickly to their origin, so populations don't drift over time. In such a scheme, one can approximate movement knowing only the initial population of each place.
The requirement
This breaks down when populations being modeled are migratory (they don't return "home" regularly) or highly variable (significant birth and/or death factors). This is especially common in animal modeling. A requirement like "10% of birds will migrate to another location each day" is going to be wildly inaccurate without knowing the real counts of birds in each location throughout the simulation.
MovementModels in epymorph's current design can't know how many individuals are present in each geo node at some time in the middle of the simulation. This limitation is fine for many movement models, but a hindrance for others, so we can improve this.
Current behavior
Movement clauses are simply functions which calculate, for a particular simulation step (tick), the "requested" movement vector between all locations (an NxN matrix). The internal movement processing logic then uses this to compute the "actual" movement (an NxNxC matrix) by randomly selecting available individuals (each of which is, at that time, grouped into one of the IPM's compartments). It's not a problem for the MovementModel to request more movement than can be fulfilled by available individuals -- the logic handles capping movement appropriately.
For typical human commuter style movement, the number of individuals currently at each location is not very important information. The number of movers is usually much smaller than the non-moving population, and movers return fairly quickly to their origin, so populations don't drift over time. In such a scheme, one can approximate movement knowing only the initial population of each place.
The requirement
This breaks down when populations being modeled are migratory (they don't return "home" regularly) or highly variable (significant birth and/or death factors). This is especially common in animal modeling. A requirement like "10% of birds will migrate to another location each day" is going to be wildly inaccurate without knowing the real counts of birds in each location throughout the simulation.