Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[stem-dev] Discussion on Chris' proposal Re: Mixing Computation

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 call before we commit a huge change.
I think you can start on a prototype but I want to have the documentation ready before we check in and also make some other tests.

1) You and Matthias are right. The use of common border edges for mixing 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 plan.

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 border edges x Number of populations or species. This is potentially a huge memory hit
ii) Today, when STEM needs to find an edge it has to iterate through ALL edges on a node to find the all the ones of the right type. Perhaps this is a defect based on our storing the
edges only by URI (and not by type) but for today, when we implement (1) there will be a performance penalty. FIxing that performance penalty will 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 facts and are useful for ii below
ii) We keep the mixing edge class class where mixing edges should store
        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 number or rate.
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. is my proposed compromise. For users that don't need the complexity of a custom mixing graph and don't want to learn how to do that, they will still have available the simple out of the box (albeit somewhat obscure) model documented on the wiki. This preserves backward compatibility, performance, and memory efficiency for all the legacy stuff but allows us 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 model 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 but this is a big enough change and important enough issue I think we need to allow open discussion on STEM-DEV and on the call next week.

Best Regards,

IBM Almaden Research Center, 650 Harry Rd.
San Jose, CA 95120-6099
email: kaufman@xxxxxxxxxxxxxxx
phone: (408) 927-2477  (tie 457-2477)

From: "Thoens Christian" <Christian.Thoens@xxxxxxxxxxx>
To: "Edlund Stefan" <edlund@xxxxxxxxxxxxxxx>, "Kaufman James" <kaufman@xxxxxxxxxxxxxxx>,
Cc: "Filter Matthias" <Matthias.Filter@xxxxxxxxxxx>, Matthew Davis/Almaden/IBM@IBMUS
Date: 03/16/2012 05:33 AM
Subject: Mixing Computation


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
shown in
And it also depends on the RoadTransportEdges and road network
infectious proportion. With this approach the user could look at all the
mixing fractions in the GraphEditor and mixing would be more
transparent. Additionally the parameters characteristic mixing distance
and road network infectious proportion would not appear in DiseaseModels
anymore, but in the MigrationEdgeGraphGenerator. That way the user only
sees these parameters if he really wants to use mixing.

Best Regards,

Back to the top