Re: [stem-dev] Food Production

[Stefan Edlund <edlund@xxxxxxxxxxxxxxx>]

Thanks Chris,

there is a problem having transformation decorators being integratable. The limitation in STEM right now is that only one disease model is allowed to calculate the next value of the disease state in a population. Let's take the slaughter house example.  So say we have a regular SIR disease model D1 for modeling infections in cattle and an SI model D2 for the beef. What the slaughter house transformation decorator is doing is really updating values of disease labels that in some sense does not belong to it. It touches the labels for D1 and D2, but it only does that at the beginning of a time step. After this, D1 and D2 are free to go on integrating the solution for the next value.

If the transformation decorator was also integrating, it would calculate its own delta value for the labels of D1 and D2, which surely would be overwritten by the delta value calculated by D1 and D2 themselves.

I'm still leaning towards having food consumption being integratable using some extended multi-population disease model. Removal of consumed meat could be represented using the BIRTHS_AND_DEATHS ExchangeType attached to the delta value of the disease state. I think you remember how this was done from last summer :)

Regards,
/ Stefan

Stefan Edlund
Public Health and Computer Science Research
IBM Almaden Research Center
(408) 927-1766   edlund@xxxxxxxxxxxxxxx


"Thoens Christian" ---01/13/2012 01:24:40 PM---Thanks for all the suggestions. First I would like to explain why I prefer to model consumption with

From:	"Thoens Christian" <Christian.Thoens@xxxxxxxxxxx>
To:	<stem-dev@xxxxxxxxxxx>,
Date:	01/13/2012 01:24 PM
Subject:	Re: [stem-dev] Food Production
Sent by:	stem-dev-bounces@xxxxxxxxxxx

---

Thanks for all the suggestions.


First I would like to explain why I prefer to model consumption with a
TransformationDecorator. For the scenarios Matthias and I want to create
integration is not a priority. The most important thing is to able to
model the food consumption in any way you want. And with the
FoodConsumer class it's easy to model many different things. Let's say
we have data that a certain amount of beef is consumed daily in a
certain region. In that case I can just set the daily consumption to a
fixed number. I can also set consumption to a fraction (such as 20% of
the whole beef is consumed daily) or I make it dependent on the size of
the human population in the region. Stefan's idea of a
FoodPopulationModel is great for modeling a consumption, that is uniform
in the whole world. FoodConsumers can be different in different regions.
I don't know yet if we will use this feature in our scenarios, but it's
an advantage, that a FoodConsumer can be used to model many different
things.


Nevertheless, making consumption and other TransformationDecorators
integrable is of course desirable. I like the idea with the
integrable-flag and I think the extra-complexity for the user is not
such a big deal. We could put a warning next to the checkbox, "Only use
this if you know what you are doing". Of course performance is a
downside and it might be difficult to implement, especially in Stefan's
RungeKuttaIntegrator.


Best Regards,
Chris


>>> James Kaufman  01/13/12 7:28 PM >>>
I think the only question issue arrises if you need the FoodConsumer to
be 
integrable.
The transformation decorator was designed to handle transformations that

are by definition not integrable
but food consumption might be. 

Here is one other thought (but one with big downsides).
Stefan suggested you use multipopulation model to handle consumption.
A food consumption decorator could store a MAP which knows at what rate 
different populations consume different foods.
We probably want to handle consumption of feed by farm animals as well
as 
consumption of food by humans.
If the foodconsumption decorator does not do the but simply stores the 
rates, then the population models could handle the decay
in an integrable way (because population models are integration 
decorators). The thing I do not like about this idea is it then makes
all
population models more complex and I wanted to hide the complexity of
food 
transformation in a separate transformation decorator.

A second thought (also with downsides) is to give the transformation 
decorator a flag to indicate whether or not the transformation is
an integrable transformation. We would then have to group any 
transformation decorators by integrability and so we call transform at
the 

right point in the iteration cycle. This also has bid disadvantages 
(performance hit as a well as a lot of complexity for the users - they 
need to
understand if the transformer can be integrable).

The best approach may be Stefans suggestion. What if we extend multi 
population model to a new class called "Food" or "Food Population".
This could have different states, death=expiration, and it could store 
a 
map=Consumers with their consumption rate. This might also be 
a
better representation of reality since consumption is not really 
transformation. Consumption is integrable. Food production is not.



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" 
To:
, 
Date:
01/13/2012 03:04 AM
Subject:
[stem-dev] Hi all,
Sent by:
stem-dev-bounces@xxxxxxxxxxx



Hi all,

I would like to make some changes to the foodproduction plugin. A class
that allows consumption of food and disease transmission by consumption
should be created. My proposal for this is as follows.

abstract base class "FoodTransformer" (or maybe "FoodProcessor", since
consumption does not transform food?)

a child of "FoodTransformer" called "FoodProducer" (maybe abstract?):
same functionality as the old class "FoodProducer"

a child of "FoodProducer" called "DiseaseCarryingFoodProducer" (or
maybe "Slaughterhouse"?): same functionality as the old class
"Slaughterhouse"

a child of "FoodTransformer" called "FoodConsumer": provides
consumption of food and disease transmission by consumption

Does anyone have any suggestions for improvements?

Thanks,
Chris
_______________________________________________
stem-dev mailing list
stem-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stem-dev





_______________________________________________
stem-dev mailing list
stem-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stem-dev