Unified Model Documentation Paper 303

Converting GRIB data to a UM Dump 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: 303
Converting GRIB data to a UM Dump via the Reconfiguration

Contents
1 Introduction 2

2 Some Cans and Can’ts of the process 2

3 Getting GRIB Data 2

4 What’s Read And How It’s Converted For UM Use 2

5 Setting Up A Reconfiguration App 3

6 Making Code Changes to Read Different Data Fields 4

1 c Crown Copyright 2015

 UMDP: 303
Converting GRIB data to a UM Dump via the Reconfiguration

1 Introduction

The UM uses it’s own defined file formats for storing data, see UMDP-F03 for details. However, the WMO
also defined a format for meteorological data to be stored and exchanged between different organisations. This
format is called GRIB (GRIdded Binary ). The Model has no mechanism for directly reading this format, but as
the Reconfiguration is the tool used to modify dumps and change resolutions prior to a model run starting, it
is also the ideal place to read GRIB data and convert it into a form the Model can read and understand. The
need for this facility was driven by the desire to be able to restart the operational forecasts from ECMWF GRIB
data as a fall back position. This means, that at present the functionality is also geared to only reading basic
information presented using ECMWF’s set of definition tables. However the design is such that the changes
required to enable the reading of additional information from ECMWF or other sources should be achievable by
following examples and not require too much depth of understanding of the code. Once alterations to the code
have been made to achieve this, they can be retained as they augment the current abilities, not replace as was
the case with previous version.

2 Some Cans and Can’ts of the process

The following list summarise the functionality of the process.

• Things that can be done.
– Read ECMWF pressure level data. ( @ vn5.5 and beyond )
– Read ECMWF model level data. ( @ vn6.2 and beyond will read vertical level parameter information
from GRIB data )
– Read ECMWF ERA40 data ( @ vn6.5 and beyond )
– Read from different ECMWF ’table 2’ specifications ( @ vn6.6 and beyond )
– Read SST data direct from surface temperature field, but only if sea-ice is in input GRIB file ( @ vn8.0
and beyond )
• Things that can’t be done....... yet
– Reconfigure from or directly onto a LAM grid
– Interpolate soil moisture and temperature data (the code assumes a 1-to-1 relationship between the
UM and ECMWF soil levels).

3 Getting GRIB Data

It is advisable to retrieve data on a resolution as close as possible to, but slightly higher than, that which is
intended to be used in the UM dump being produced. The Reconfiguration has been tested using Lat/Long
grids of 0.25 degree resolution. At present the data is required to be global and on a Lat/Long grid. Spectral or
sub-domain information are not catered for.
The retrieval of GRIB data is deemed to be beyond the scope of this document. Users are urged to read the
section ’Obtaining Data from the ECMWF Archives’ in UMDP-000 ’The Unified Model User Guide’, Section B3.

4 What’s Read And How It’s Converted For UM Use

At present, the Reconfiguration is only equipped to handle a few fields. These are :
• Single / Surface level fields.
– *Geopotential Height (z), converted to Orography by dividing by g.
– *Land Sea Mask (lsm).

2 c Crown Copyright 2015

 UMDP: 303
Converting GRIB data to a UM Dump via the Reconfiguration

– *Skin Temperature (sk), Used as surface temperature.

– *Surface Pressure (sp).
– Soil temperature (stl1/stl2/stl3/stl4)
– Volumetric soil water (swvl1/swvl2/swvl3/swvl4), converted to soil moisture content by multiplying by
layer depth.
– Sea-ice fraction (ci), with this field SST can be taken from Skin Temperature (no Sea-ice or SST
ancillaries)
– Snow depth (sd), converted to Snow amount by multiplying by 1000.
• Model level 1 only fields
– Log(Surface Pressure) (lnsp), converted to surface pressure by exp(lnsp)
• Multi-level (Pressure or Model level ) fields.
– *U wind (u).
– *V wind (v).
– *Temperature (t), Interpolated as Temperature then converted to ThetaT.
– *Specific Humidity (q).
– †Ice water content (qcf).
– †Liquid water content (qcl).
– Cloud Fraction and Water Contents (cc/clwc/ciwc), Need to all be used together
– Ozone (o3)
– Various GEMS chemistry species (nox,ch4,co,hcho,o3)
The fields marked with a * are required to produce a UM dump from which a forecast can be run. Fields marked
with a † are only required when using the ENDGame dynamical core. All the other fields are optional. 1
Note: While the Reconfiguration can handle W wind, the vertical interpolation has a tendency to produce a
dynamically unbalanced result causing early failure of the UM forecast (<24hrs). It is therefore deemed more
prudent to set W wind to zero which is done by default if W wind is not present in the GRIB data file. There is
work afoot to ensure better quality assurance from the interpolated dumps which may change this in the future.
Note: Some other fields are not read from the ECMWF GRIB file and are set to specific values, these are as
follows:
• All cloud fields are set to zero in the dump, hence these will spin up as the forecast runs.
• Boundary layer depth is set to 500m, this is required to prevent a divide by zero for 8B and 8C boundary
layer schemes. (@vn6.1 and beyond)
• Surface roughness length is set to 0.5m, this removes the need to import the obsolete MOSES1 vegetation
ancillary file (@vn6.5 and beyond)
• The advected U and V wind components are set to be equal to the actual U and V wind components.
(@vn6.5 and beyond)

5 Setting Up A Reconfiguration App

As the reconfiguration is preparing a dump for a model run, it takes most of the information required from that
provided to run the model itself. To this end, even when running a job that is reconfiguration only, it is necessary
to define the model sections that will be used by the model correctly. It is because of the necessity to have all
the relevant model sections defined that copying an app which reconfigures from GRIB is unlikely to be the best
1 Log(Surface Pressure) can replace Surface Pressure.

3 c Crown Copyright 2015

 UMDP: 303
Converting GRIB data to a UM Dump via the Reconfiguration

starting point. It would probably be easier and more efficient to take the model run app and convert it to run
from GRIB data.
In the recon namelist change input dump type to 2 : “Input dump is in ECMWF GRIB format”. Once done,
the initial dump, specified on the same panel (namelist item ainitial), is the file which will be read into the
reconfiguration and should be the GRIB data file. The file and path specified by the nlcfiles namelist item
astart is where the reconfigured UM dump will be written to and subsequently used by the model run itself.
In an ideal world this would be all there is to it. It is however unlikely to work. As the fields retrieved from the
GRIB data file are so few in comparison to what would have been found in a UM dump, there are likely to be
fields which, while not present in the Input dump, are also unlikely to have an alternative source specified. Many
fields do have a default source set when reconfiguring from GRIB data, and that is normally to set the field to
zero. However those fields where it would be better to read the data from ancillary files do not have a default
source set as the user still needs to provide the path to the ancillary file. If, when run, the Reconfiguration
produces an error report such as :
*****************************************************************************
ERROR!!! in reconfiguration in routine Rcf_Set_Data_Source
Error Code:- 30
Error Message:- Stashcode 32 : Required field is not in input dump!
Error generated from processor 0
*****************************************************************************
This is precisely the problem. In this case the field is “SEA ICE DEPTH” as identified by the stashcode. The
Reconfiguration will fail in this manner at the first field it reaches where there is no source specified, there are
likely to be more. The options are keep re-running the Reconfiguration until all missing fields have been found
and suitable sources selected for them, or, run the Reconfiguration with the output level set to a verbosity higher
than ’PrintStatus Min’ using the RCF PRINTSTATUS environment variable.
This level of verbosity causes a list of fields to be included in the output dump, along with a list of fields included
in the input dump. From the list in the output dump, select those which can be read from ancillary add a new
items namelist for each ancillary file. Set the file name and path using namelist item ancilfilename. The
namelist item source should be set to 2 : configure from ancillary and the STASH codes of the items to be
configured should be entered in stash req. If no such suitable ancillary file exists then the user must select
one of the other available sources to initialise that prognostic from. See ’HOWTO - Initialise a Field via the
Reconfiguration’ in UMDP-302 for more details.

6 Making Code Changes to Read Different Data Fields

The standard Reconfiguration executable is quite capable of making a valid start dump from an ECMWF GRIB
data file, however, to allow the Reconfiguration to make use of other fields available but not yet catered for, the
actual code of the Reconfiguration must be altered and a new executable be compiled. The most basic change
that can be made, would be to add a new parameter which has a direct equivalent in the UM. To do this it is
probable that the only deck that needs to be altered will be RCF_GRIB_LOOKUPS_MOD.F90. The user will need to :
• Increase the number of lists, these are the storage spaces for the field header data. One list for each
parameter but each list can contain multiple fields or levels.
• Define, and assign, the parameter for that list number. Increase p Max Rows, this is the number of entries
in the cross-reference table used to define the UM STASH item codes which correspond to the GRIB
parameter ID codes.
• Add the data to the cross-reference table itself, the format of which can be easily copied from the other
entries present.
Note: The corresponding parameter definitions for the GRIB ID code and the stashcode need to exist in the two
relevant modules. If they don’t then they will also need to be added.
This will allow the Reconfiguration to recognise a GRIB parameter and inform it of which Stashcode field it will
become in the UM dump.

4 c Crown Copyright 2015

 UMDP: 303
Converting GRIB data to a UM Dump via the Reconfiguration

To allow data to be read from a new center, another column needs to be added to the cross-reference table,
along with all the entries in that column for the existing parameters. Also a new center number parameter will
need to be defined at the appropriate place.
The level of complexity involved in setting up the Reconfiguration to read in parameters which will need some
calculation or transformation before they become the UM parameter required, depends greatly on the complexity
of those transformations. For a very simple example of a simple transformation it is suggested that the user look
at the code in RCF_GRIB_SPCL_CTL_MOD.F90 and RCF_GRIB_SPCL_OROG_MOD.F90 which converts geopotential
height to orography. It may be wise at this juncture to contact the relevant member of the UM SYSTEMS
Development team to discuss the changes required.

5 c Crown Copyright 2015