model system
A model system is a set of different models sharing the same infrastructure.
Example: ECHAM5/MESSy including the box-models and tools.
model
A model is represented by one executable.
Examples: ECHAM5/MESSy (echam5.exe), the MECCA box-model (mecca.exe), …
submodel
A submodel is the implementation of one process according to the MESSy coding standard, i.e., split into the submodel core layer (SMCL) Fortran 90 module(s) and the submodel interface layer (SMIL) Fortran 90 module(s).
box-model
A box-model represents one process in its smallest meaningful entity (e.g. box (0-D), or vertical column (1-D)) as a stand-alone executable.
model distribution
A set of files representing a model or model system, usually archived as zip- or tar-file.
Examples:
- echam5.3.01_messy_1.11_src.zip
- messy_2.55.0_src.zip
model version
The model version is indicated by the version-number(s) of the model distribution; and is also contained in the code and output to log-file(s).
Examples:
- echam5.3.01_messy_1.11_src.zip
- messy_2.55.0_src.zip
The model version is only valid for code without modifications! In other cases it is a modified version.
In the case of a model system, each component may have its individual version number.
submodel version
The submodel version is indicated by the version number in the submodel core layer (SMCL) file of the submodel.
Example: CHARACTER(LEN=*), PARAMETER :: modver = ‘1.1.3b’
model configuration
The model configuration is the scope of model characteristics selected at configuration-time or at compile-time, which cannot be changed during run-time, but which do not require manual code changes.
Examples:
- automatic code generation, e.g., MECCA, SCAV mechanisms (including intermediate code processing (e.g., for vectorisation or de-indexing))
- architecture / compiler selection
- preprocessor options, e.g,
- parallel (MPI) or single CPU executable
- ECHAM5 with MESSy or without
- compiler options (e.g., error checks, degree of optimisation)
model setup
The model setup is the scope of model characteristics determined at run-time.
Examples:
- ECHAM5:
- horizontal / vertical resolution (determined by the initial-/rerun-file(s))
- upper (mid-) boundary (e.g., middle atmosphere (MA)), (determined by namelist switch)
- parameters and switches in ECHAM5 namelists
- initial and boundary conditions (e.g., AMIPII-SST, data-files)
- MESSy:
- selection of active submodels (ON/OFF)
- coupling between submodels, and submodels and basemodel
- initial and boundary conditions (including emissions !)
- parameters and switches in submodel namelists
model mode of operation
A model mode of operation is a subset of the model setup (i.e., determined at run-time), which describes a specific characteristic that can be combined with other characteristics.
Examples:
- “nudged mode”: application of Newtonian relaxation of meteorology to assimilated (analysis or re-analysis) data
- “quasi chemistry transport model (QCTM) mode”: absence of feedback from chemistry on dynamics
- “chemistry-climate model (CCM) mode”: interactive chemistry with feedback on dynamics
BaseModel Layer (BML)
The Base Model Layer (BML) ultimately consists only of a central clock and run-time control, currently however, typically of a general circulation model (GCM) or a box model.
BaseModel Interface Layer (BMIL)
The Base Model Interface Layer (BMIL) comprises the basemodel specific implementation of the MESSy infrastructure; it can be regarded as a multiple socket outlet for the communication between the basemodel and the submodels.
SubModel Interface Layer (SMIL)
The submodel interface layer (SMIL) represents the connector of a specific process to the infrastructure (BMIL).
SubModel Core Layer (SMCL)
And last but not least, the submodel core layer (SMCL) comprises the basemodel independent implementation of a specific process in the Earth System, or of a diagnostic tool of the model system. It can be regarded as an operator using the data provided via its SMIL and providing data back via its SMIL to other submodels and/or the basemodel.