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

[James Kaufman <kaufman@xxxxxxxxxxxxxxx>]

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