wiki:RegionalModel
Last modified 5 years ago Last modified on 12/04/2012 11:05:12

Conceptual model for regions

A ZIP archive for playing with the Cantal case study can be downloaded here.

This archive contains the executable jar of the model, a little manual (README.html) and the set of data for the Cantal (french department).

Javadoc is here

Simulator usage

Command line options:

 -b,--batch-mode         Use the batch mode (no GUI)
 -i,--input <filename>   Input file

Please see the page about simulation parameters.

Logging configuration (for developpers)

You can configure the level of logging for several object. In the development version, you can edit the file src/main/resources/fr/cemagref/prima/regionalmodel/logging.properties (available in Netbeans under "Other sources") to choose the level among WARNING, INFO, FINE, FINER or FINEST to get a less or more verbose behaviour.

You can also adjuste the verbosity for a specific municipality by giving its name. For example, adding this line in the file will set the verbosity to FINER for the municipality 15054:

fr.cemagref.prima.regionalmodel.Municipality.15054.level=FINER

When you are running an exploration, this is the file src/main/resources/fr/cemagref/prima/regionalmodel/logging-exploration.properties that is used.

Model implementation details

Scenarios

Scenarios deals with the exogenous modification of the system state along the time. So you have to consider a scenario as a set of discrete events that will occur during the simulation. A Scenario describes the number of events that can occur during the simulation.

The goal of a scenario instance is to represent one exogenous dynamics. It's important to understand, that our conception is to create as many instance of scenario as we want describe such dynamics. At simulation time, this set of scenarios will be easier to assemble and configure than big scenario with an messed goal. These instances can be created using the class DistributedTableUpdater, or by derivating your own scenario implementation from the class Scenario or the intermediate class TableUpdater.

As you can see, the class Scenario requires to implement the method getTotalNbOfEvents(): int. This number of events will be used with the distribution method to build a schedule and determine at which time step and how many times for a time step the simulator should invoke the step method of a scenario. This mechanism has been introduced for controling the way the scenario will act on the system at the simulation time.

The class TableUpdater provides a convenient way to define scenario that will be loaded from CSV input files for a set of municipalities. This class will directly apply a delta using a method of the class MunicipalitySet specified with the parameter updaterMethodName. The specified method should be annotated with the annotation @Updatable. The set of municipalities can be configured with a filter (class MunicipalitiesFilter).

The configuration of the scenarios to use in a simulation will be loaded with the XStream library. It means that XML element will correspond directly to class and attributes defined in the model. For instance, you can edit manually a XML file to add and configure a scenario to a file. But it's planned to use a GUI that will allow to add and configure your scenarios and generate for you the XML file. For now, you can see a sample here.

Attachments