===== 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. New doc needed for 1.3
Status: No additional updates
* Dengue
* Initializers
* Loggers
* Malaria (done)
* Mosquitos VCAP (done)
* Shape file importer (NEW)
* Solvers
3. Bug of the week: bug 353939 Project Explorer broken when STEM workspace path contains a space
is this really a bug? Can we close it?
4. Items for Newsgroup this week??
Item on new framework for error handling and messages
Item on new loggers?
5. Update on Dengue model status
JK implemented Newton-Raphson to solve couples nonlinear equations (matlab class) to test/confirm steady state solutions for full model.
6. New Malaria mapping algorithm
Status: Moving forward, will input into paper
7. STEM NLS language packs are up on Babel
Status: Will send note when all is done & all are ready
Todo: (1) Delete Migrated files from SVN; (2) New Property Files from Stefan, must update Babel for 1.2.3 release (on website)
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. Report from Stefan on New Error handling
Please see four issues/questions below (re disease models, population models, error messages, & cloning);
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 automatically generates
an instance of a StandardPopulationModel with zero background birth/death rate. The question was whether this is perhaps more confusing to the user than helpful, and perhaps it's better
to force the user to explicitly add the population model manually. This would also make it clear to the user what the background birth and death rate for the population is. An alternative
suggestion was made to make it an option when creating a disease model whether to also automatically add the zero birth/death rate population model for it.
Propose: A. With added error/warning message we get rid of this helper feature.
B. If A. passes should this be for Release 1.2.3 or 1.3.0 ?
ii) Right now, population models must be located beneath 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: STEM design philosophy (portability and reusability of models). Let's get a list of proposals including
Proposals??:
A. Create new, Population Re-scaler object, specifically to reset population by calendar (should iii come before ii ?)
B. Eliminate the nesting requirement
C. Require Nesting but with change A, tolerate parallel placement of populations and disease models
D. ?? other alternatives
iv) discussion on cloning. This would be a huge change.
10. Items from participants
