getin files
Let us look first at the special format of text files that will be
read by the procedure getin
. We start with this because it is used
for various conceptual categories of input.
The getin
files have the suffix .def
. There must be a file called
run.def
, it is the first file read. Other getin
files are read
only if there is a corresponding INCLUDEDEF
line in
run.def
. Cf. the distributed
run.def. For
example:
INCLUDEDEF=physiq.def
Syntax of getin
files:
- variable=value
- Case sensitive
- TRUE or FALSE for logical values (you can also use
y
orn
) - Character values without quotes
- Comment lines start with #
Be careful with getin
files ! There is not much control done by the
procedure getin
:
- The order of assignments is free.
- The distribution of assignments among
getin
files is free. - If you assign values several times to the same variable, the program will not stop, the last assignment will be used.
- You will not get an error message for a mistyped parameter name in
your
getin
files, it will just be ignored. - Parameters used in the Fortran source files need not all appear in
the
getin
files: they have default values in the Fortran source files. As a matter of fact, the distributedgetin
files (in directory DefLists) do not mention all the parameters. Moreover, the default value of a parameter in the Fortran source files may not be the recommended value, for the sake of backward compatibility.
So it is easy to make mistakes when preparing the getin
files. Fortunately, there is a way to check: each run creates a set of
files used_*.def
. You can see in them all the parameters that were
actually used for your run, including those which you did not specify
in your getin
files and received default values.
Note there is also a
script
for easier comparison of two sets of getin
files.
Although, as we have seen, the distribution of assignments among
getin
files is free, people normally use five getin
files (for
LMDZ alone, without Orchidee), with specific meanings. The point of
this separation is to distinguish sets of parameters which are
"orthogonal": one getin
file can be replaced without conflict with
another. Here are the five getin
files:
gcm.def
: dynamicsphysiq.def
: parameterizationsvert.def
: vertical discretizationconfig.def
: coupling with other models, type of ozone and aerosol forcing, concentation of greenhouse gasesrun.def
: length of the run, dates, calendar