The MCP, CGP, and Driver applications are configured using a simple configuration format, which is described in the following sections. The configuration commands (config-cmds) referred to in this section are documented in section 7.
When running under the command line interface, the MCP, CGP, and Driver applications read configuration files from the Project ‘Config’ directory to customize their behavior. (When running under the java interface, these commands may be viewed and edited from the Configuration panel ). In general, only the Driver configuration is important, but it is possible to configure the MCP and CGP apps if necessary. The MCP config file can be used to automate the process of adding/deleteing SMML code to/from the SMML file each time it is generated ( e.g. ignoring some variables or adding user-defined functions ).
In the default configuration, the following configuration files are read/written by these applications:
<ModleName>.MML.config read (if exists) and written by MCP
<ModleName>.<scenario>.config read (if exists) and written by CGP
<ModleName>.<scenario>.config~ initial config file backup generated by CGP
<ModleName>.<scenario>.config read by Driver
If MCP or CGP fail to find a config file then they generate and write a default version. The MCP, CGP and Driver apps are usually never executed directly, but are invoked by the SME script (or java interface tool) with appropriate arguments. Developers may determine the command-line arguments to these apps by executing them with the -help argument ( e.g. executing ‘MCP -help’ gives a list of the MCP command-line arguments).
All configuration files follow the same format. The reader may want to examine a sample configuration file, such as <ProjName>/Config/<ModelName>.def.config from one of the sample projects included in the distribution. Default versions of all the configuration files are generated by the SME applications.
A configuration file is structured as a set of records, usually with a single record on each line. Each record begins with a special character, called the "class character", belonging to the set { #, $, *, ~ }, and continues until the next class character is encountered. The class character denotes the class of object that is being configured. Each object class accepts it's own unique set of configuration commands (config-cmds). Table 1 lists the current set of class characters with the corresponding object class and config-cmd sets. The various config-cmd sets are described in detail in section 7.
After the class character, the next field in a record is the object name. There is always a single model object called "global". Other object classes (Module, Variable, and External) may have many objects as defined in the SMML (or View) equation files. The class characters and object names are generated by CG and should not be edited by the user.
|
Class Character(s) |
Object Class |
Config-cmd Sets |
|
* |
Variable |
Variable Cmds. |
|
$ |
Module |
Module Cmds. |
|
# |
Model |
Model Cmds |
|
~ |
External |
External Cmds |
Table 1: Configuration classes.
Following the object name in each record is an optional space-delimited list of config-cmds. Some config-cmds will be generated by default by CG. The user can edit the default config-cmds and/or enter new config-cmds. The config-cmds are in the form x(ArgList), where x is the config-cmd name (a character or character string, but usually one or two characters), and ArgList is a list of configuration parameters, i.e., arguments, which are separated by commas when more than one argument is used. Spaces between arguments are ignored. The number and type of arguments depend on the config-cmd being entered. Arguments may be either text strings (e.g., a variable name), integers, or floating point numbers. Arguments may either be required or optional. The ordering of config-cmds is usually irrelevant (the OS() config-cmd is one exception), but the arguments of ArgList must be presented in the order given in the documentation below.
Commands may be commented out by placing a ‘|’ character inthe command list: this character causes all commands following it to be ignored until the end of the line is reached.
For example, a typical record in a configuration file might look like:
* elevation_MSL_map d(G,Elevation_map,1.0,0.0)
In this record, the class character '*' indicates that a variable object is being configured. The name of the variable object is 'elevation_MSL_map'. One cmd is used to configure this variable. The d(G,...) config-cmd from the variable c-cmd set configures map input such that the map Elevation_map is read from Grass ( ‘G’ argument ) and used to initialize elevation_MSL_map. Following arguments set the elevation_MSL_map scaling parameters to (1.0,0.0).
For another example, a typical record in a module configuration file might look like:
$ VEGETATION_SECTOR g(G,StudyArea)
In this record, the class character '$' indicates that a module object is being configured. The name of the module object is 'VEGETATION_SECTOR'. The g() config-cmd from the module config-cmd set then configures the module such that is will be linked with a 2D grid frame, initialized with the map StudyArea (read from Grass).