Unified Model Documentation Paper 302

Initialising a Field via the Reconfiguration

UM Version : 10.1
Last Updated : 2014-12-05 (for vn10.0)
Owner : Joe Mancell

Met Office
FitzRoy Road
Exeter
Devon EX1 3PB
United Kingdom

c Crown Copyright 2015

This document has not been published; Permission to quote from it must be obtained from the Unified Model
system manager at the above address
 UMDP: 302
Initialising a Field via the Reconfiguration

Contents
1 Why Would I Want To Initialise A Field ? 2

2 Initialisation via Namelist Inputs 2

3 Initialisation in the Reconfiguration Code 2

1 c Crown Copyright 2015

 UMDP: 302
Initialising a Field via the Reconfiguration

1 Why Would I Want To Initialise A Field ?

• When introducing a new scheme or parametrization, an initialisation of a field may be required. It is

possible to do this in the model, but as space in the dump will need to be setup via the reconfiguration,
it is sensible for initialisation to be performed here. Indeed, the reconfiguration insists on some form of
initialisation for any field it puts in the dump.
• For the purposes of scientific investigation it may be useful to setup certain fields from (for example) a
reference state in a different dump from the one that is the main input. The reconfiguration can handle this
via data transplants.

2 Initialisation via Namelist Inputs

A number of initialisation methods can be specified via the items namelists. These can be found in the “Recon-
figuration and Ancillary Control” section of the GUI.
This has the following actions available for initialisation, using the source namelist variable:
1. This option is the reconfiguration default. The field is looked for in the input dump. If it is found it is either
copied or interpolated (if grid or orography have changed) into the output dump. If it is not found the
reconfiguration will use internal logic to decide what action to perform.
2. Set from Ancillary. This is useful if a user-ancillary file has been specified in development of new schemes.
In normal use, the ancillary file is pointed to within the corresponding ITEMS namelist.
3. Set to Zero. All the values of the field on all levels (or pseudo-levels) are set to 0.
4. Set MDI. All values of the field are set to the Missing Data Indicator. This is -2**30 for real valued fields
and -32768 for integer valued fields. There is no Missing Data Indicator for logical fields.
5. Tracer File. This allows the input from an external dump format file (with the same validity date) of a field
with the same STASH item code as the field that is being initialised. Originally intended for initialisation of
Tracer fields, but can be used more widely.
6. Set to a user-defined constant. All values of the field will be set to a constant supplied by the user. The
namelist input insists on a real valued constant, but this is converted to an integer as appropriate for
integer valued fields.
7. External Dump. A field can be extracted from an external dump (ie other than the input dump). The field
with the specified item code is used to initialise the field in question. Note that in this case the initialised
and the external dump field need not have the same item code.
8. Field Calculations. This option allows you to supply code to initialise the field via some calculations. As
this requires a code change (to specify the calculations). Further details of this option are given below.
Another initialisation that can be used is that of transplanting data. This allows a user to take a sub-area of a
field (specified as a Cartesian block of rows, columns and levels) from an external dump to replace the values
in the output dump. This is a post-processing step and some other form of initialisation will be required for the
field as a whole (as the non-sub-area has to have been already initialised). Transplants are accessed using the
trans namelist in the “Reconfiguration and Ancillary Control” section of the GUI.

3 Initialisation in the Reconfiguration Code

If a new prognostic field is being introduced for a scheme or parametrization, it is appropriate that users should
have minimal effort to initialise this field if the scheme is chosen. Often ancillary files are the appropriate
method - this will not be covered here. In other cases it may appropriate to set the new field to 0, a constant or
via calculation. This may be achieved fairly simply via a small code change applied to the reconfiguration.
The routine Rcf Set Data Source is where fields that do not exist in the input dump (and have not had initial-
isation methods specified via the namelist) can have their initialisation method set. This is done via a Case

2 c Crown Copyright 2015

 UMDP: 302
Initialising a Field via the Reconfiguration

statement based on STASH item-code. The initialisation methods 1-8 above are all available here, although
those requiring external files (2, 5 and 7) are probably not appropriate. Authors are reminded to avoid use of
magic numbers and to use the parameters from Rcf DataSource instead.
When calculations are required, the Field Calcs initialisation method should be used (this is sometimes referred
to as ”source = 8” initialisation). In this case, new code will be needed to perform the calculations required for
the initialisation. This should be done in a subroutine that is called from Rcf Field Calcs. There are numerous
examples called from Rcf Field Calcs which can be used as templates for new initialisation methods.

3 c Crown Copyright 2015