To make results reproducible and traceable, we kindly ask you to
refer to the model system at least once in the text of each of your papers,
presentations, proposals etc. as indicated in the section
MESSy Citation Rules of the
MESSy License description.
Some more suggestions for wording in publications, proposals,
presentations, etc. can be found below.
A model system is a set of different models
sharing the same infrastructure.
Example: ECHAM5/MESSy including the box-models
A model is represented by one executable.
Examples: ECHAM5/MESSy (echam5.exe),
the MECCA box-model
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
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.
A set of files representing a model
or model system, usually
archived as zip- or tar-file.
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).
The model version is only valid for code
without modifications! In other cases it is a
In the case of a model system, each
component may have its individual version number.
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'
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.
The model setup is the scope of model characteristics determined at run-time.
- 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)
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
- horizontal / vertical resolution (determined by
- 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,
- 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
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.
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.
The submodel interface layer (SMIL)
represents the connector of a specific process to the infrastructure (BMIL).
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.
- "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
This page was last modified on
31 Jan 2017.
If you have comments or suggestions, e-mail me at