2014 March Status Phase 1 - openmpp/openmpp.github.io GitHub Wiki

OpenM++ phase 1 completed in March 2014 with following results (enumeration corresponds to OpenM++ design document, which also describes tasks):

• OpenM++ compiler (2.1 priority1): alpha version, working beta version with 60% functionality coverage
  • types (classifications, ranges, partitions)
  • parameters (exogeneous)
  • agents
  • variables (25% complete)
  • inter-agent links
  • events
  • cross tabulation (except margins)
  • meta-information (except labels & groups)
• OpenM++ controller for MPI cluster (2.2 priority1): beta version
• OpenM++ modelling library (3.1 priority1): beta version
  • case-based and time-based models
  • agent & event lifecycle
  • event queue
  • on-the-fly cross-tabulation updating
  • Modgen-equivalent random number generators for exact output comparability
• OpenM++ model data storage design (3.2 priority1): beta version
• OpenM++ data library (3.3. priority1): beta version
• OpenM++ execute library (3.4 priority1): beta version

On top of essential phase 1 Roadmap tasks following items completed:

• compatibility layer for Modgen source model code .mpp files (2.3 priority2): alpha version
• OpenM++ output result viewers and model analysis tools, import/export into R (1.2 priority2): beta version

Deferred items mentioned in phase 1 Roadmap:

• all optional items (except two listed above) due to limited resources
• compatibility converter for Modgen parameters .dat files (2.3 priority1) postponed after extensive design discussions.
• components of OpenM++ compiler (2.1 priority1) due to limited resources
  • agent collections
  • parameters (endogenous)
  • variables (75% remaining)
  • cross-tabulation (margins)
  • meta-information (labels & groups)
  • derived tables
  • other miscellaneous functionality

Overall results of OpenM++ phase 1 cover most of existing Modgen desktop functionality (excluding GUI).

OpenM++ foundation created as result of phase 1 project and it is opens up following four streams for subsequent development:

• model stream: ongoing work to move existing Modgen models onto OpenM++ platform
• cloud stream: build openM++ cloud PaaS and/or SaaS stack, emphasizing on scalability. Time: 11 months
• tools stream: creating openM++ desktop GUI based on Visual Studio, Eclipse or similar for model developers and users. Time: 9 months
• core stream: enhance openM++ core functionality, for example, modelling results post-processing and analysis.

Tools and cloud stream partially described in OpenM++ Design and Model Architecture documents.

Core stream task list is very flexible because it is generally include OpenM++ small core enhancements required for other development streams.

For example, as it is today, beta version of OpenM++ supports only SQLite as model database storage and cloud version of OpenM++ most likely require at least one of MySQL, PostgreSQL, Oracle, MSSQL or DB2 support. Due to flexible nature of core stream development it can be done incrementally as long as resources available, however it is very important strictly follow OpenM++ Design documents to make sure we are proceeding to the right direction and avoid common "creeping featurism" mistake.

Following tasks are required to be completed before or during OpenM++ cloud or desktop GUI development (enumeration corresponds to OpenM++ design):

• OpenM++ output converters:
  • 2.5 priority 1: export into .csv for parameters and output results. Time: 10 days
  • 2.5 priority 2: export into .xml for model data or user-defined subset of model data. Time: 16 days
• OpenM++ SQL loaders. Time: 4 weeks + 10 days for each db-vendor
  • 2.4 priority 1: MS SQL, MySQL / MariaDB
  • 2.4 priority 2: generic SQL99
  • 2.4 priority 3: PostgreSQL, Oracle, DB2, Apache Derby, H2 or HSQL
• extend data library to support MySQL, PostgreSQL, Oracle, MSSQL or DB2 (3.3 priority3). Time: 3-4 weeks for each db-vendor
• completion of OpenM++ core support for i18n / L10n in runtime library. Time: 3 weeks
• Modgen .dat files compatibility converter (2.3 priority 1): required design decision. Time: from 10 days to 6 weeks.
• exploratory subsamples suite for OpenM++ models (see below). Time: between 5-9 weeks

Their is no fixed order in the list above, it can be implemented as required by other project or OpenM++ users.

This is high priority component which defined in OpenM++ design document (2.3 priority 1) as command-line utility to convert existing Modgen models data into OpenM++ format. It was originally planned for phase 1 development, but deferred due to unresolved design dependency with other parts of OpenM++, i.e. cloud model publusher or SQL loaders mentioned above.

There are two important aspects of .dat-convertor design:

• language complexity of .dat file syntax, which is in fact c++ initializers syntax with Modgen extensions
• environmental complexity of .dat-convertor use cases

Environmental complexity actually means variety of .dat-convertor use case scenarios in not yet well defined runtime environment. Please look at explanation on OpenM++ model use cases in Model Architecture document for more details.

Some examples may include:

• developer:

  • uses local Windows or Linux PC with GUI
  • often recreate SQLite database and load input data hundred times to debug the model
  • eventually need to pack model executable and data files and send it to researcher

• researcher:

  • HPC cluster (large or small) or local Windows, Linux workstation without GUI
  • run the model thousand times loading wide variety of input data from prepared .dat files
  • do not have admin privileges, especially on cluster, as result, can not install or adjust runtime environmemnt
  • often need to pack model .dat files to publish it, move from local PC to HPC cluster or share with other researchers

• institutional user:

  • uses web UI to run the model in cloud, on HPC cluster or other powerful server environment
  • have absolutely no access to actual server environment
  • receives initial set of input .dat files from developer or researcher and want to upload it into cloud database
  • cloud database most likely one of: MySQL, Oracle, MSSQL, PostgreSQL, DB2

From examples above you can see following requirements to model input data tools:

• it must be portable and can not assume specific OS or database
• user may have no access to actual model database (i.e. model developer have no access to cloud instance)

Possible solutions for .dat-files converter in context of above requirements:

• due to language complexity of .dat files it is nice to use OpenM++ compiler (omc) to parse it
• omc read .dat files and saves as:
  • c++ values compiled into model executable, which in turn, saves it into target database during first run
    • pro: everything in one file, ideal for consistency and transfer
    • cons: model executable is huge, which increase compilation and execution time
    • pro/cons: it is not possible to change model input data without re-compilation
  • SQLite database
    • pro: compact storage
    • pro: ideal for model developer (or even researcher) as no any other steps required to run the model
    • pro: there are many standard utilities to browse or edit the data
    • cons: extra tool required to import from SQLite into actual database in cloud environment
  • sql script files
    • pro: portable and human-readable format
    • pro: no any other tools required to transfer data from one environment into another
    • cons: least compact storage, size of input data files are largest of all
  • some other text format, i.e.: .csv or .xml files
    • pro: portable and human-readable format
    • cons: some custom tools required to load the data from such files into model database

We must keep in mind when choosing .dat-converter solution couple of other items from OpenM++ design document:

• OpenM++ must have SQL-loader utilities to facilitate data export into different model databases
• OpenM++ must have utilities to export input (and output) data into other formats, i.e.: text .csv and .xml files

That means we can relay on presence such OpenM++ utilities in foreseeable future.

Current OpenM++ model subsamples design is Modegn-compatible. It was done on purpose to provide Modgen model developers and users familiar concepts and even ability to reuse existing tools within OpenM++. However, there is fundamental limitation in that design, which became obvious when OpenM++ model runs in HPC cluster environment.

For example, if we have 16,000 CPUs cluster then it may be make sense to prepare 1000 different sets of input parameters, submit model job with those 1000 inputs * 16 subsamples each to use all 16,000 CPUs and analyse results to find optimal set of model parameters. It is possible to do in OpenM++ now by specifying working set of input parameters for and run the model 1000 times by submitting 1000 jobs to the cluster. However it would be nice to have such capability incorporated in OpenM++ runtime to allow simply submit single job with 1000 different sets of parameters and 16 subsamples each.

To implement such feature following changes in OpenM++ required:

• execution library: organize model MPI groups to effectively broadcast input parameters to slave modelling processes
• model database schema: allow multiple sets of input parameters for each model run (Modgen allow only single)
• model database schema: store relationship between input set and output results inside of single modelling job
• data library: redesign output results aggregation to do it over related output values (now it is done across all subsamples)

That feature should significantly increase model users productivity and allow more effective HPC cluster resource usage. It is recommended to have it for OpenM++ cloud version.