Introduction

For the projects  like TIGGE, S2S, UERRA or LC_WFV it is important to have good checking tools deployed on the both ends of the processing chain, provider's and ECMWF's ones, to avoid common operational problems related to preparation and dispatching the data.

Find below some examples what we use to do at ECMWF as a part of the operational data processing suites. If you are our data provider, please try to install similar checks on your end to minimise our common future support effort. It would help us handling increasing number of similar projects in a sustainable way and without additional resources. 

Checking data delay

It should be checked that the data production and dispatching is done within expected time frame. This can be of high importance as some data products cannot be produced any more after a longer delay from whatever reason (e.g. full model results which are needed are kept only for limited time).

There are many ways how to check the delays, depending on the data provider's production chain e.g..

  • regular cron based check
  • automated log file analysis by software like splunk

Checking data content

Following checks should be done before providing the data:

  • Data encoding check
  • Comparing data content against reference
    • the number of the fields must be as expected
    • the actual field list must be the same as expected
  • Data quality check
    • the best and most complete quality control can be done by a custom made tools only, e.g. during the forecast computation by the model
    • the basic quality control can be done using the dedicated ECMWF tools which are simply checking the allowed limits (min/max values in each grid point) of each parameter

Checking data transfer success

If data is pushed to our premises, the following steps can ensure smooth dispatching:

  • Make the transferred file "invisible"
    • e.g. by adding the dot before the file name and rename it only after the transfer is finished
    • that way the ECMWF's automated acquisition action will not be triggered prematurely
  • Compare the file sizes before and after the transfer
    • the file size must be identical to ensure the file was not corrupted during the transfer (should be done still before the file renaming)