Eclipse Community Forums: Spatiotemporal Epidemiological Modeler (STEM)

Home » Eclipse Projects » Spatiotemporal Epidemiological Modeler (STEM) » (Asia) Mosquito Density Model(Additional description would be helpful)

Show: Today's Messages :: Show Polls :: Message Navigator

(Asia) Mosquito Density Model [message #670236]

Fri, 13 May 2011 07:50

Matthias Filter

Messages: 75
Registered: July 2009

Member

Hi,
I was testing the (Asia) Mosquito Density Model and was wondering a bit, what actually happens mathematically in the model. Unfortunately I was not able to locate those information in the wiki and also in the model I did not find those answers.
As far as I understood there are actually only two anopheles specific items in the model:
the "anopheles.standard" population model and the "AnophelesInitializer.standard" initializer. How are now the earthscience data integrated into the model calculation? Is this a compartment disease model at all?
From the wiki entry on "available models" there is only the following text:

Mosquito Population Model

The mosquito population model in STEM uses environmental earth science data (available in the STEM library) to estimate the average mosquito population for a region. The model has been calibrated from a study done in Thailand where the field measurements were taken on the number of bites per person in a day. First, the model takes into account factors such as rainfall, vegetation, temperature as well as elevation when estimating the potential number of mosquitos per (human) host. Next, actual estimates for mosquito population is calculated by multiplying by the number of humans available in the region. If no data on the host is available, a scaling factor of 1 is used (hence the reported number is the potential number of mosquitos/host). By default, the model assumes that female mosquitos exclusively take blood-meals from humans. However, the host does not have to be human, it can be changed to say birds, monkeys or lizards if such population data is available. It is possible to scale the mosquito population using any desirable scaling factor. More background information on how the model was calibrated can be found in the 2009 doctoral dissertation by Arisara Charoenpanyanet, entitled "Anopheles Mosquito Density Predictive Model Based on Remotely Sensed Data," done at the Asian Institute of Technology, Bangkok, Thailand.

In my understanding the STEM model description should contain all information that a user need to reproduce what is calculated without the need to look up a text book or a PhD thesis. What do you think?

Report message to a moderator

Re: (Asia) Mosquito Density Model [message #670344 is a reply to message #670236]

Fri, 13 May 2011 15:25

James Kaufman

Messages: 240
Registered: July 2009

Senior Member

Hi Matthias,
This population model is not a compartment model and not a disease model. It's also still a bit in progress. I can send you a preprint describing the model in detail but it is much like a USGS model that estimates Mosquito (Anopheles) risk based on a mathematical model fitting various climate data to actual Anopheles surveys. The downloadable model was fit against data from a PhD thesis in Thailand.
We (Stefan) has now build a MacDonald Ross Malaria model (compartment model) on top of the population model. This led us to reevaluate some of the calibration and to switch from daytime temperature to nighttime (Anopheles bites at night). We will probably update the downloadable model with additional documentation and references once the paper is submitted.

Report message to a moderator

Re: (Asia) Mosquito Density Model [message #671292 is a reply to message #670344]

Tue, 17 May 2011 12:03

Matthias Filter

Messages: 75
Registered: July 2009

Member

Hi Jamie,

what became clear to me in this example is the fact, that we should find a generic solution for the documentation of the model equations that are calculated in a stem model. As far as I could see there is currently no field in the dublin core where one could fill in the equations that are computed. Or could one extract that information automatically from the source code? In my understanding this information should be mandatory to provide otherwise the concept of reusability of models can not be followed.

In this context a different issue came to my mind as well. We had earlier the discussion on the migration vs. common border edges.
If I remember right the actual common border edge value that is used in the model calculations is calculated from the area of the neighbouring entities. (according to the wiki page: http://wiki.eclipse.org/Transportation_Models ). But here again we have the problem, that reusability of graphs is hard to assure if the documentation of what is actually calculated is not directly connected to the item. So either we find a solution to describe these preprocessing calculations in the dublin core of each edge or we change all common border edges to migration (mixing) edges, so that a user can look into the canonical graph right away and see what the mixing rate between two geographic entities is. If we would prefer the second option then we should use the dublin core to describe that the values originate from a preprocessing step. Maybe it would then also make sense to create a folder for "supporting functions", where we could collect all types of preprocessing routines that one might need.

Report message to a moderator

Re: (Asia) Mosquito Density Model [message #671430 is a reply to message #671292]

Tue, 17 May 2011 21:34

James Kaufman

Messages: 240
Registered: July 2009

Senior Member

Matthias,
I'm not certain I understand you comments in full (and I think this thread now has more than one subject so we should probably split it).

Regarding:
>As far as I could see there is currently no field in the dublin core where one could fill in the equations that are computed.

Do you really mean the equations or the equation parameters? I'm now working on an HTML summary generation that will summarize ALL run parameter and dublin core for any scenario. Will have a prototype for your soon. I don't think we ever intended the equations themselves to be in the dublin core. There is no automatic way to do that. In my opinion the equations for each mathematical model (each Java class) should be documented (1) On the wiki and (2) In the javadoc with the class. It might be problematic to represent them in a Dublin Core as the equations themselves could be quite complex. We could include a link from the dublin core to the wiki page (or to an outside page). The Dublin Core supports this but it will depend upon users filling it in.

I'm confused by your comment on edges. Edges themselves have no equations and no values. The parameters for transportation are a part of the population model (for example). The values of the parameters are logged and will be in the new html summary. That's feasible for the population models. We can easily have many tens of thousands of individual edges in a graph so I think we need the graphical editor if the user wants to explore them individually.

I'll start a new thread on the html summary report - I'd like your comments on it. Again this will deal with only the parameters (not the equations). Extending the documentation on the equations themselves should probably be another separate thread where we can talk about linking the dublin core to more rich documentation.

Report message to a moderator

Re: (Asia) Mosquito Density Model [message #671572 is a reply to message #671430]

Wed, 18 May 2011 11:24

Matthias Filter

Messages: 75
Registered: July 2009

Member

Concerning the edges: I thought that the parameters for transportation are calculated once in the beginning to create a "canonical model". Currently the graph editor can only visualize "canonical graphs" and not such "canoncial models". So the user currently has no chance to check whether the transportation parameters make sense or not. From some of the graphs that I looked at with the graph editor I have the gut feeling that it might be worth the effort to have an in depth look also at the transportation / mixing parameters used during calculation.

Report message to a moderator

Previous Topic:	Interventions
Next Topic:	STEM at Eclipse Day India

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Dec 06 05:47:31 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter