Find in this page technical specification of the required input data and processing workflow.


  • Output type:  forecast

    • only one forecast product per centre is expected for verification - the best available one for the common inter-comparison

  • Output time: 00, 6, 12, 18 UTC (depending on availability)
  • Output frequency: between 1 and 6 hours (including step 0 encoded as forecast type as well)

    • the model output steps should be the shortest available
  • Wave parameters should be obtained from the full 2-D spectrum (we stress this fact as there seems to be some confusion about wave parameters' names and definitions even in the latest WMO GRIB2 code tables)

  • Follow the links for exact GRIB2 WMO compliant definitions
  • *1 valid in ECMWF's ecCodes only


All details about the required data format can be found in the page Encoding details.

Sample data

  • Providers are asked to provide full sample data from one model run containing all expected parameters, steps, forecast types etc.
  • Naming convention for sample data:
    wave_<centre WMO origin>_<YYYYMMDDRR>_<prod/test>_fc.grib2
    prod/test ... production or test version of the data
    fc ... forecast (step 0 should be also encoded as of forecast type)
  • Merge all parameters from all steps for given model run and output type into one file:
    e.g. wave test forecasts from ECMWF on the 1st of September 2017, 12Z  => wave_ecmf_2017090112_test_fc.grib2
  • Put sample data on ecgate to a directory with reading permission
    • alternatively use any other downloadable location (e.g. google drive)
    • alternatively use this ftp:

  • The naming convention for future production data might change

Production data acquisition

  • The data will be pulled via ftp from an agreed server location at the data producer's site.
  • The ECMWF's acquisition system will be used for handling the production data exchange.
  • Participants are committed to guarantee a steady and reliable provision of their data and to communicate any relevant changes.
  • The support mailing list on provider's side will be required to allow smooth communication related to common production issues in the future.


Contact Richard Mladek for any further details, sample data exchange etc.