Support vector-valued flows with mp_discrete_stoch()?
#288
Comments
|
(previous comment deleted ... I was on the wrong track earlier) Your question has really helped me think @papsti . Please let me know if you have any questions about what I wrote below so I can clarify it better in my own mind. The General IssueBranching flows and stratification are two kinds of model structure that interact when using Assumptions to Bound Scope
Note that these are genuinely restrictive assumptions. For example, it is not possible to have The ProblemWith these assumptions the
Because the state variables are already vector valued, it would require 'fancy' bookkeeping to have a single vector that kept track of both stratification of state variables and of branching of flows. In other words we are trying to use vectors for two things: (1) representing grouping structure and (2) representing branching of flows. Proposed SolutionTo make
This is about a day of focused work and will break the existing Visualizing the ProposalConsider this branched flow involving vector-valued state variables, graph LR;
S-->I
8000
m;
S-->Is;
In the above proposal, this vector-valued diagram expands to the following element-wise diagram. graph LR;
S_1-->Im_1;
S_1-->Is_1;
S_2-->Im_2;
S_2-->Is_2;
Note that if we try to stratify the graph LR;
S-->I;
Because the vector-valued diagram doesn't describe branching, the corresponding element-wise diagram would also not describe branching. We would have to have something like this. graph LR;
S_1_m-->I_1_m;
S_1_s-->I_1_s;
S_2_m-->I_2_m;
S_2_s-->I_2_s;
What these pictures show is that each vector-valued diagram translates into parallel element-wise diagrams that all share the same branching pattern. For example, lets look at one branched flow in one of the element-wise diagrams above. graph LR;
S_1-->Im_1;
S_1-->Is_1;
Note that all states are from stratum In short, I'm proposing to use (1) different elements of vectors to represent strata and (2) different vectors to represent alternative branches through a diagram. What About Examples without Branching Flows?You may be wondering, @papsti , but my example does not involve branching flows! The problem is that the second argument of the Complexities and Down the RoadIf we all like this proposal, we will need to create new flow functions (i.e., not just We will need a way to flow within vectors (e.g., We will also need a way to handle movement from one specific element in one specific vector to a specific element in another vector. The above makes the user handle the functional form of the state-dependent per-capita flow rates on their own. This could get confusing if there are multiple types of stratification (age-by-geog-by-immunity). The user will need to do things like Kronecker products, which I would rather not force them to do. So probably what we need are helpers for specifying the per-capita flow rate arguments. What I am thinking is something like this: Where the The stuff in this down-the-road section is what paralyzes me when designing a stratification interface. But I do think that @papsti's use case is going to be common enough that we should just implement it as proposed above. |
|
Here is a good minimal example to use when working on this stuff. |
|
thank you for writing all of this out---that helped enormously. i appreciate the complexities of this problem when you're thinking of asking i think your proposal for my usecase is a sound first step. i have an iteration on the idea that might simplify the problem. i think the issue becomes really difficult in general because we want macpan to respect constraints with branching flows, but the rate is treated as a monolith, and we're not leveraging the fact that the user is actually sp
8000
ecifying how the branching should occur in the rate expression. perhaps this insight could inspire a more useful spec, particularly when setting up equations with for instance, in the very helpful example above, the rates into the if so, perhaps there could be something like |
|
I like this idea. It would involve adding another flow function, but that might be worth it. One nice thing for development time is that we ask the user to tell us how many branches there are, which will likely be useful for specifying the internal logic. Thanks. |
|
sounds good. for the record, the model i seek to recode has a number of branched flows, so this is extremely relevant to me currently. |
|
I am wondering if the This interface could have benefits for #267. |
|
Related to #188. |
how difficult would it be to support vector-valued flows with
mp_discrete_stoch()?for instance, the current implementation of the
sir_agestarter model leverages vector-valued flows to easily stratify the basic SIR by age (or metapop structure) as described here, but i wouldn't currently be able to generate discrete stochastic equations as noted here.i'm not sure if the concerns with doing this are computational or mathematical or both? could we spell them out a bit to discuss feasibility of this feature?
being able to easily go from simulating deterministically to stochastically would be a strong incentive for me to recode the spec for a model i'm currently using heavily. this would be most useful for me if it could be done in the next month or two, but would still be useful beyond.
The text was updated successfully, but these errors were encountered: