===== Conf Call Agenda =======
1. Release planning
Reminder: Will release STEM 1.2.3 on Nov 21 (RC1 Nov 1); need to delete old property files. Target date for 1.3 is still (1/07/2012)
* Ten years of Earth Science Data (2000-2010) available as STEM ''Features''
* Malaria Disease Model (''Anopheles'' calibrated)
* Dengue Fever Disease Model (''Aedes'' not yet calibrated)
* Additional NLS + User ability to switch languages
* Logger Framework with new loggers
====Release new loggers for 1.2.3
====Delete old loggers and views for 1.3
* Shape File Import Utility (Dependency on Open Map CQ)
* Integrating external models for study of food based transmission
* New Differential Equation solver(s) from commons.math library
* Bug Fixes from 1.2.2
*** Need presentation slides for 1.3
2. Developers, please see Matt's note to STEM DEV and do an update (lots of new changes).
3. New doc for 1.3
* Dengue
* Initializers
* Loggers
* Malaria (done)
* Mosquitos VCAP (done)
* Shape file importer (NEW)
* Solvers
4. Bug of the week: bug 314785 Decorator Validation
Is this part of Stefan's new work on validation/error handling? (way to extend?)
5. Items for Newsgroup this week?
6. Update on Dengue model status
Rerunning with longer times to reach steady state.
Simone visit Nov 1st
7. New Malaria mapping algorithm
Status: Moving forward, will input into paper
Data from N. Waraporn with both Dengue and Malaria data from Thailand.....
8. Ideas for future STEM demos
>FD vs Integration
>Data Import example (playback)
>Data input example (initialize from csv)
>Data logging image and data examples
>Dengue Fever example(s)
> what else?
>>> Can we do a YouTube on each one ? Stefan, what did you use to do the screen captures?
>>> Need to plan code freeze November 1st so we have 1 month to build and test scenarios for workshop
9. Discussion items
i) When a disease model is initialized (creating and initializing the disease model label and label values needed to keep track of the dynamically changing state of the disease),
it depends on having a population model (of the same population identifier) with its label/label values already initialized beforehand. If it cannot find one, it used to automatically generate
an instance of a StandardPopulationModel with zero background birth/death rate. We will no longer do this. Now that we have multiple disease models this is confusing. New error handling will prompt
user to correct the scenario.
Discussion: Should this be for Release 1.2.3 or 1.3.0 ?
ii) Right now, population models must be located beneath the the disease model in the model hierarchy. The only real reason why they can't be at the same level is that for Standard Population Models
(with fixed background birth/death rate), the population numbers are adjusted to correspond to the starting date of the sequencer. So if the population data is valid 2006, and the sequencer starts in 2011,
the numbers are advanced five years given the background birth/death rate. The disease model must be aware of this when it is initialized so it must be above the population model.
Again, the question is whether this is confusing the users more than helping them. Also, since we have many other types of population models that does not change the initial population numbers from the start
of the sequencer (e.g. seasonal, mosquito), perhaps we should get rid of this feature altogether.
and iii) If we were to get rid of the feature, perhaps replacing it with an alternative method such as using a "population re-scaler" is a better option. This has the benefit of working for any type of population model used.
Discussion:
A. Should we create new, Population Re-scaler object, specifically to reset population by calendar (should iii come before ii?) instead of the population model.
B. This would eliminate the nesting requirement (but not the design philosophy)
10. Items from participants
