[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[stem-dev] Antw: Discussion on Chris' proposal Re: Mixing Computation
You are right about the downsides. And implementing MixingEdges is not
a priority for me right now. Let's talk about this in the next call.
>>> Matthias Filter 3/19/2012 10:04 am >>>
I think this is an excellent suggestion!
>>> James Kaufman <kaufman@xxxxxxxxxxxxxxx> 16.03.2012 18:04 >>>
Thank you very much for this suggestion. I'd like to suggest a small
extension to your proposal and ask that we discuss this on next weeks
before we commit a huge change.
I think you can start on a prototype but I want to have the
ready before we check in and also make some other tests.
1) You and Matthias are right. The use of common border edges for
are not transparent and effectively invoke a very simple model. We need
the ability for users to
i) Invoke a different mixing model
ii) customize edges
iii) see the edges and values
This is why we had the mixing edge class - it was sort of always in
However, there is a big downside to (1) for many users.
2) The downside
i) An extended model required a set of mixing edges = Number common
edges x Number of populations or species. This is potentially a huge
ii) Today, when STEM needs to find an edge it has to iterate through
edges on a node to find the all the ones of the right type. Perhaps
is a defect based on our storing the
edges only by URI (and not by type) but for today, when we implement
there will be a performance penalty. FIxing that performance penalty
be another memory hit.
iii) For users that do not need to do (1), creating custom mixing edges
adds complexity and makes it harder to learn to use STEM.
I'd like to propose the following for discussion next week.
3) The proposal
i) We keep common border edges - these simply represent geographical
and are useful for ii below
ii) We keep the mixing edge class class where mixing edges should
a) The population name they refere to (eg cattle)
b) Fraction or number mixed in a time period
c) boolean to indicate fraction or number
d) time unit in ms
iii) We do what you say and create the mixingEdgeGenerator class
iv) Users who chose to, or need to, can use 3.iii and create a custom
mixing model, visible in the editor, and configurable edge by edge and
population by populatiion
v) In the code, when the disease models asks for
"getEffectiveInfectious()" we will look for mixing edges (just like we
look for road edges) and if the mixing edges are found
it will execute the highly transparent user defined mixing graph by
vi) HOWEVER, if no mixing edges are found the code will REVERT to the
default build in mixing model we have now based on the common edges.
3.vi is my proposed compromise. For users that don't need the
of a custom mixing graph and don't want to learn how to do that, they
still have available the simple out of the box (albeit somewhat
model documented on the wiki. This preserves backward compatibility,
performance, and memory efficiency for all the legacy stuff but allows
to support the custom mixing without changes to our disease models.
4. Downsides to my suggestion.
i) We will still have a field for "mixing distance" in the disease
wizard. Maybe we add a better context sensitive help on this field.
ii) I think we need to put 2.ii in plan. If you want to run a big model
with lots of populations we may need a faster way to find exactly the
right subset of edges for each type of mixing. need a memory efficient
design for this as it will be a change to STEM core.
What do you think? If this seems reasonable it's fine to get started
this is a big enough change and important enough issue I think we need
allow open discussion on STEM-DEV and on the call next week.
IBM Almaden Research Center, 650 Harry Rd.
San Jose, CA 95120-6099
phone: (408) 927-2477 (tie 457-2477)
"Thoens Christian" <Christian.Thoens@xxxxxxxxxxx>
"Edlund Stefan" <edlund@xxxxxxxxxxxxxxx>, "Kaufman James"
"Filter Matthias" <Matthias.Filter@xxxxxxxxxxx>, Matthew
03/16/2012 05:33 AM
I was thinking about the way mixing with CommonBorderEdges is done and
that Matthias would like to have a more transparent way to it. What do
you think of the following approach?
Right now mixing is done in the DiseaseModels based on
CommonBorderEdges and RoadTransportEdges. We could create a
MixingEdgeGraphGenerator like the MigrationEdgeGraphGenerator. The
MigrationEdgeGraphGenerator would create MixingEdges (the class I just
deleted) that contain the fraction of people who are mixing. This
fraction depends on area, common border length and mixing distance as
And it also depends on the RoadTransportEdges and road network
infectious proportion. With this approach the user could look at all
mixing fractions in the GraphEditor and mixing would be more
transparent. Additionally the parameters characteristic mixing
and road network infectious proportion would not appear in
anymore, but in the MigrationEdgeGraphGenerator. That way the user
sees these parameters if he really wants to use mixing.