[stem-dev] Antw: Discussion on Chris' proposal Re: Mixing Computation

["Thoens Christian" <Christian.Thoens@xxxxxxxxxxx>]

Thanks Jamie,

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.

Best Regards,
Chris

>>> Matthias Filter 3/19/2012 10:04 am >>>
I think this is an excellent suggestion!

Best,
Matthias

>>> James Kaufman <kaufman@xxxxxxxxxxxxxxx> 16.03.2012 18:04 >>>
Chris,
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.

so....
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.

3.vi 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,
Jamie

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



Hi,

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
http://wiki.eclipse.org/Transportation_Models#Mixing_Approximations.
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,
Chris