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?]]>

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

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

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