>INIT_OUT run_id outDir dumpFreq dumpFormat dumpStatus nout
outFormat gradsNc outStatus yrevOut
zrevOutSoil,zrevOutSnow numMonth
useTemplate undefOut zsmc,zst outEndian
Table 38 Description of variables in the INIT_OUT section.
Variable name Type and permitted values
Notes
runID character*10 A name or identifier for the run. This is used to name output files and any model dumps.
outDir character*150 The directory used for output files. This can be an absolute or relative path. Enter ―.‖ to write output to the directory from which JULES is run.
dumpFreq integer
2: dump initial and final model states
3: as 2 but also write a dump at the end of the spin-up phase
4: as 3 but also write a dump at the end of each calendar year.
A model dump captures the state of the model at a given point in the integration. If a final dump is saved, the integration can later be extended by starting another run from this final dump. For long integrations, or large domains, it is recommended that dumps are saved for every year, so that in the event of any trouble such as a model crash, the integration can be completed without having to start again from the initial state. NB A run that is carried out in several steps, each starting from the model dump for the previous step, will generally not evolve identically to a single run that proceeds without the intermediate dumps. This is due, in part, to a loss of precision when the model state is written to the dump file.
dumpFormat character
‗asc‘ or ‗nc‘
Format for dump files. ASCII or netCDF.
dumpStatus character
‗new‘ or ‗replace‘
The file status used when writing a model dump.
Acceptable values are:
‗new‘ – if a file with the same name already exists, the run will terminate.
‗replace‘ – if a file with the same name already exists, it will be overwritten.
nOut integer The number of output profiles. Each profile generates a separate stream of data, as explained above.
outFormat character The format for output files. Acceptable values are:
‗asc‘: ASCII files
‗bin‘: flat binary files
‗nc‘: netCDF files
gradsNc logical Switch controlling details of netCDF output files.
Only used if outFormat=‘nc‘.
TRUE: netCDF output will be constructed so as to be readable by GrADS. In particular, snow layer variables will be split so that each tile is represented with a separate variable (otherwise there are too many dimensions for GrADS to cope with).
FALSE: netCDF output might not be readable by GrADS (but in many cases is).
outStatus character
‗new‘ or ‗replace‘
The status used when opening files. This is the value given to the FORTRAN ―status‖ argument of an OPEN statement [ e.g. open(1,status=’new’) ], or the equivalent for netCDF files.
‗new‘: file must not already exist. If the code tries to create a file with the same name as an existing file, the run will terminate.
‗replace‘: If the file exists, delete it and replace with a new version.
yrevOut logical TRUE: reverse the order of the rows in the output, so that these are written in ―North to South‖ order.
FALSE: use the default ―South to North‖ order, with the southernmost row of data being the first in the file.
zrevOutSoil logical Switch indicating if soil layer data are to be output in reverse order of levels compared with JULES‘s default.
TRUE: reverse the order of the vertical levels in the output, so that these are written in ―bottom to top‖
order (i.e. bottom layer first).
FALSE: use the default ―top to bottom‖ order (i.e. top layer first).
zrevOutSnow logical Switch indicating if snow layer data are to be output in reverse order of levels compared with JULES‘s default.
TRUE: reverse the order of the vertical levels in the output, so that these are written in ―bottom to top‖
order (i.e. bottom layer, closest to soil, first).
FALSE: use the default ―top to bottom‖ order (i.e. top layer first).
numMonth logical Switch controlling the date format used in file names.
TRUE: months are represented by the numbers 1 to 12.
FALSE: months are represented by 3-character strings (jan, feb, mar,…)
useTemplate logical This relates to GrADS files (generated by outFormat=’bin’ or ‘nc’).
Switch to activate the writing of template ‗.ctl‘ files.
A template ctl file allows GrADS to access several data files via one ctl file.
TRUE: all suitable ctl files will use the template
option.
FALSE: generate a separate ctl file for each data file.
Note: A template ctl file will not be able to describe the data if there are any missing times at the start of a file – this is a limitation of the current JULES code, rather than GrADS. For example, if daily data are to be written to monthly files, with a template ctl, but the run starts midway through the month, JULES will only write output data for the latter part of the month.
GrADS will look for data for all days in the month, but not be able to find them, so the user will not be able to plot the first month.
undefOut real The value written to output files to represent ―missing‖
or ―undefined‖ data.
zsmc real If a depth-averaged soil moisture diagnostic is requested, the average is calculated from the surface to this depth (m).
zst real If a depth-averaged soil temperature diagnostic is requested, the average is calculated from the surface to this depth (m).
outEndian character
‘little_endian’
or ‘big_endian’
Only used for GrADS output files (outFormat=’bin’), this describes the byte ordering of the computers on which JULES is run. It is only included in the ‗options‘ line of GrADS ctl files, i.e., in metadata describing the file. It does NOT alter the byte order of the output.
Acceptable values are:
‗little_endian‘ – for little endian computers (e.g.
PCs)
‗big_endian‘ – for big endian computers (e.g. Suns)
6.20.2. NEWPROF: details of each output profile