Interoperability Workshop

ECMWF, Reading UK 14 -15 January 2008

Participants

Martin Miller, Alfred Hofstadler, Baudoin Raoult, Gabor Radnoti, Tiziana Paccagnella, Ulrich Schaettler, Jean-Francois Geleyn, Martin Janousek, Jeanette Onvlee, Xiaohua Yang, Trond Iversen, Andras Horanyi, Bartolome Orfila, Jose Antonio Garcia-Moya, Terry Davies, Alan Dickinson, Jim Sharp, Rachel North, Alan Radford and Bruce Wright.

See presentations and the minutes of the meeting after it

1. Agenda and presentations

2. Meeting report

By Jim Sharp, Europe Manager, Met Office

The chair welcomed attendees to the meeting. He thanked ECMWF for hosting the event. Dominique Marbouty, Director of ECMWF also welcomed the meeting to the Centre and wished delegates a successful workshop. He explained the importance of interoperability to the Centre

Aims and objectives of the workshop

presentation of Alan Dickinson (Chair)

Alan Dickinson presented the history of the Interoperability programme and the desired outcomes from the workshop.

Andras Horanyi clarified some aspects of the history from the point of view of the original redaction team (mainly that the original proposal was already endorsed by the EUMETNET Council, but no responsible centre was found afterwards).

Tiziana Paccganella noted that some members of EUMETNET Council wished to include all of the original proposal including deliverables D5 and D6. Alan Dickinson responded that they were not so specific, but had indicated that they wanted as much as reasonably possible from the programme and this needed to include the availability of lateral boundary conditions from global models.

A. dISCUSSION OF TECHNICAL ISSUES AND CURRENT AND PREVIOUS EXPERIENCE

The first afternoon of the workshop had a series of presentations describing the experiences of participants and the issues generated.

The scope of the interoperability system and the relevant application areas

presentation of Terry Davies, Met Off

Terry presented more detailed information, setting out some of the options for priorities and areas for work. He noted that initial priorities might include the ability to compare the output from models, an ability to use the output in a standard verification system, the ability to use output in an ensemble, and how to deal with sub-model processes such as surface exchanges.

The kinds of option for a common format were introduced, along with a discussion on the issues arising from different model grids and how to reconfigure from one model system to another. For instance:

• Handling of non-atmosphere fields, eg, surface, orography, chemistry.
• Different atmospheric variables, resulting from using different model formulations
• Need to exchange information to allow appropriate data conversions.

During discussion it emerged that there is probably insufficient knowledge of the data volumes involved, which is a concern for the success of the project. It may be necessary to agree on the format and parameter list and estimate volumes later. INM noted that in their experience 1 set of input from a GM (40 levels x 5 parameters, 3 hourly steps to T+90) requires around 1GB.

Xiaohua Yang commented that the eventual solution may depend on the effort we are prepared to put into maintenance and maintaining quality.

Jeanette Onvlee commented that it was important to enumerate and document the steps involved in any data conversion.

There was discussion on whether a single or multiple solutions represented the easiest way forward, but there was general agreement that the number of interpolation steps should be minimised.

The chair noted that discussion so far had considered only NWP data, while the previous EUMETNET proposals included observations. Following discussion it was agreed that observations should not be considered in this tranche of work, but should be borne in mind as the project progresses. No centre is yet in a position to use another's processed observations, so the requirement is lower priority. As model resolution increases however it will become increasingly important to include observations in the system and of course the verification programme has an obvious requirement.

Discussion on the scope of the programme noted that there was more to do than could be accomplished in the 2 years currently envisaged. It was considered important however, to set a scope which took the project close to success, with a smaller scope to be completed in 2 years.

INM experience with multi-model ensembles

Presenttion of Jose Antonio Garcia-Moya, INM

The System focuses on extreme events and surface parameters. It is important to get perturbation techniques right. The system runs 5 limited area models from 4 global models (It is hoped to add the Canadian GM) to build a 20 member ensemble.

Data is received from the GM providers in its original format and resolution and convert to the format required by INM.

Issues:

• Operational priorities of supplier centres sometimes mean late delivery of data.
• Development and maintenance of interoperability software.
• Human resources for monitoring then delivery and utility of data are important and should be noted for the interoperability system.
• Centres providing global model data as input to the system apply different charges and conditions. It is important to achieve a clear European policy for commercial rights when using operational data from other centres.
• The presented results showed that it was important to introduce boundary perturbations.

There was discussion on the handling of various aspects, including surface parameters. INM noted that in some instances following discussions with the data provider changes are made to parameters to estimate the required equivalent.

INM were asked to provide examples of the maintenance problems they encounter. They responded that these included changes to provider model configurations and delays in the arrival of the provided data, which can increase the elapsed time of the system. Routine diagnostic checks are made to ensure that any changes are producing reasonable outputs, but this takes human resources.

Interoperability with regard to boundary conditions

Presentaion by Alfred Hofstadler, ECMWF

Alfred described the experiences of the ECMWF boundary conditions (optional) project and the issues that arose. These included:

• Data currently only available in GRIB1 format. Special grids currently also not supported. In the long term the production system will need to be modified.
• Timeliness; some systems have shorter cut offs than can be handled. They have to use previous runs until production system can be modified.
• Non members request access to the system.
• EPS boundary conditions. These will clearly become a bigger factor.

Early problems included dealing with changes, particularly to vertical resolution and in early stages for rotated grids. The Centre interpolates to the user's horizontal resolution.

The ALADIN view of the way forward

Presentationby Jean Francois Geleyn

Jean Francois talk was based on the experience of the ALADIN community using ARPEGE, which has a very complex horizontal grid structure. This experience suggested a number of principles and questions that the group may consider. These include

• Developments for D4 should be reusable as much as possible for D5 and D6.
• Interpolation should be minimised.
• Separate two issues of vertical structure (and variable content), orography, surface characteristics and variables, from horizontal geometry.
• Common standard should be concentrated on vertical structure. Handling of horizontal grid issues should be on a bilateral basis between provider and user.
• Single exchange file format is required.
  • Exchange files should be responsibility of producer on bilateral agreement basis.
  • Horizontal interpolation for final production should be responsibility of user.
  • Data interpolation/conversion in the vertical should be responsibility of producer.
• For vertical content 2 possible solutions: Bilateral agreement and A common intermediate standard (recommended)
• Choice for orography is similar. But what is "common" orography. Possibility of having different orographies between upper air and surface computations
• Providers should include generation of commonly agreed post-processed parameters which are not re-constructible post dissemination, eg PV.
• Special attention is needed to surface parameters and characteristics. Also to cloud and precipitation properties if exchanged for post-processing.
• Staggering issues should be part of exchange file format.
• The project should agree a common list of variables/parameters and a metadata system for maintenance and documentation.
• Avoid being simplistic and model specific when dealing with surface issues.
• Separate common and local development needs.

Interoperability aspects of TIGGE LAM

Presentation by Tiziana Paccganella.

Tiziana described the experiences of the TIGGE LAM system in dealing with many of the same issues being considered for the Interoperability Programme. Interoperability is a fundamental consideration of TIGGE LAM.

2 options discussed within group to deal with initial and boundary conditions:

1. A common format. With a predefined horizontal and vertical grid and variables. This produces clear well defined output but suffers from loss of accuracy due to double interpolation
2. Data in original format. This overcomes the accuracy issue, but runs into normal interoperability problems

The former was chosen, but following experience a new 3^rd solution emerged: For providing centres to disseminate data in the original format, but for them also to provide a tool box to help the user handle the output data.

No definitive solution has yet been reached, and the group is looking to this workshop for further discussion and guidance.

TIGGE LAM has devised a standard list of parameters to be provided on agreed set of levels, using GRIB 2. on regular 0.1 deg lat/long grid. Full resolution fields are available at originating centre.

AD asked about time scale for implementation? None in place yet until interoperability issues are solved. That is why Tiziana is concerned about packages D5 and D6 being delayed.

Item 8c - Experience in TIGGE with NETCDF vs GRIB2

Presentation by Baudouin Raoult

This covers the groups experience exchanging large amounts of data in TIGGE.

GRIB2 was chosen as the exchange format. The data provider supplies interpolation on to regular lat/lon grid. Many tools are also made available.

Homogeneity is paramount to success of TIGGE. Common terminology, common data format and units, common list of products. At the moment model resolutions, base times, forecast lengths and number of ensemble members are not homogeneous.

Baudouin also discussed the issues surrounding GRIB to NETCDF conversion.

NETCDF is a very popular format in the research community. GRIB is a series of messages, each with metadata and data. It is a template based record format and can be easily extended.  It lends itself particularly to the dissemination of NWP data. It is also a WMO standard format.

NETCDF has all the metadata followed by a series of multi-dimensional arrays. It is a file (rather than record) format. Merging or splitting files is not trivial. There is no way to support multiple grids, eg change of resolution.

NETCDF does not pack as well as GRIB 2. Generally 2 to 8 times larger than GRIB.

True interoperability requires

• Date format, units.
• Clear definition of parameters
• Common tools
• Strong governance
• Grib2 vs NETCDF
• Different usage patterns
• NETCDF file based, little compression, needs a convention
• GRIB2 record based,

Baudouin also demonstrated the TIGGE data access portal.

Technical aspects of GRIB2 vs NETCDF

Presentation by Bruce Wright Met Office

Bruce examined the utility of the NetCDF format in more detail and explained why it had become the Met Office standard choice for future internal data exchange. Thought the points previously made about the relatively poor packing and compression of NetCDF were currently true, work is ongoing aimed at improving the situation and NetCDF 4 may have better packing available.

Bruce also felt that NetCDF was more flexible and capable of dealing with varying horizontal grids and time steps than the earlier discussion. It can be made flexible with multi-array descriptions and there are ways of sweeping up reduced grids efficiently.

There were further questions on the utility of NetCDF and its efficiency at storing varying fields, eg limited levels varying grids. Bruce explained that it can be made flexible with multi-array descriptions.

B. PREPARATION OF THE INTEROPERABILITY PROPOSAL

The 2^nd day of the workshop was spent rationalising the previous day's technical information and making decisions on how to take the project forward and formulate the proposal for EUMETNET council in May 2008.

Summary of technical issues

Presentations by Rachel North and Ulrich Schättler

The rapporteurs summarised the key technical issues and emerging patterns from the previous day. This summary was met with general agreement.

Formulation of Proposal Chair and Secretary.

The chair led the group through a range of topics, taken from the rapporteurs' summary and his own opening presentation to seek consensus. Discussions led to the following decisions:

1. Should the project deliver a system based on strong governance or leave things to producers? The strong governance approach was favoured. This does not preclude working with centres outside of the agreement, where the principles can be applied as much as possible. This means we need to define a common format.
2. Should observations be included in common format? Not at this stage.
3. What parameters and ancillaries need to be included? We cannot agree today. We could use TIGGE list as starting point and produce a strawman list. For production a small list is required. A larger list is required for NWP interoperability and possibly a third longer list to include research diagnostics. A minimum list of common variables is necessary. Specific issues relating to vertical staggering, model specific variables and specialist horizontal grids needs further consideration.
4. What is high priority to complete and potential quick win? A multi-track approach may be appropriate. Eg simpler production list, or TIGGE LAM approach. At the same time working towards the more complex deliverables in D5&D6.
5. What is the preferred common exchange format (GRIB2 vs NetCDF). There are merits in using either, but GRIB2 is a more compact way of storing data and it lends itself to dissemination and is the preference to become the common exchange format. Migration to NetCDF may be a desirable outcome as it becomes more developed to meet our needs. The project could set out the requirements that have to be met to initiate a migration to NetCDF.
6. The project should facilitate the re-use of available software to provide input and output in the common exchange format for the user and provider communities.
7. An output from the project should be the documentation required to operate the system.
8. Maintenance is a key issue and ongoing cost to centres using the interoperability system. This must be highlighted in the proposal. The ALADIN consortium has documentation on the procedural aspects of pre-testing and can make this available to the project.

Modification of the Programme Deliverables.

The original EUMETNET invitation to become responsible member for the interoperability programme specified 6 deliverables:

• D1: A report documenting the standard output format and including a list of parameters for which the standard output format is applied.
• D2: A report documenting the standard observational data format.
• D3: Requirements and Specifications for the adaptor software. This document includes the identification of the methods that can be used for implementing the adaptors, and for maintenance of the software in connection with the consortia. It must be agreed by all groups involved.
• D4: Four adaptors that transform the output from every LAM to the standard output format. This includes the software as well as the documentation.
• D5: Enhancements to existing software tools, that enable all LAMs to process data from the four available GMs. This includes the software as well as the documentation.
• D6: Enhancements to existing software tools, that enable all LAMs to process data from the other LAMs. This includes the software as well as the documentation.

The above discussions lead to the following suggested changes to these deliverables

• D1: Maintenance of documentation and ongoing maintenance of the standard needs to be added.
• D2: Requirement to make the standard future proofed against the addition of processed observations should be added to D1 and D2 as is removed.
• D3: Add that Met Office will coordinate the work, with consultation with GM providers
• D4 will fall to consortia to complete work.
• D5 as is
• D6 delineated as part of D5

Options

The programme timescale should be formulated to specify a number of "guaranteed" deliverables, eg post processing interoperability. It should also specify deliverables that will be worked towards, with the caveat that they probably will not be achieved in the 2 year time frame and may lead to a request for more funding in future years, eg the handling of surface parameters.

Costs

246K available over 2 years. This will fund coordination and work done by consortia. This will not fund work required by individual nations to adapt their systems. (Option 1 of the Met Office proposal to 31^st EUMETNET Council).

Finally it was agreed that based on the discussions during this workshop the MetOffice will write the draft proposal to the EUMETNET Council, which will be circulated prior to its submission between the workshop participants.