The following points are a summary of the discussions we had (Tim Stockdale, Stephanie Johnson, Charalampos Karvelis and Eduardo Penabad) about the plans for encoding seasonal forecast data in GRIB2, providing the inputs from RD, C3S and CERISE/ASPECT projects.

Distinction between real-time forecasts and re-forecasts (hindcasts)

  • There is no clear-cut distinction here on what is a forecast and what a hindcast, and from the point of view of RD having a distinction can be an unnecessary complication.
  • However there might be some merit in doing the distinction for users' benefit:
    • Using different MARS streams (as for medium-range, extended-range) is seen as unnecessary here
    • The use of typeOfGeneratingProcess=15 (Hindcast) from Section 4, code table 3 is seen as appropriate
    • The distinction between section 4 templates 1,11 and 60,61 (the latter only add modelVersionDate) is not strictly needed


Description of the forecast system

  • Alternatives to the MARS "system" keyword:
    • The use of generatingProcessIdentifier (bit 14 from section 4 templates) can be problematic:
      • IFS cycle might not be enough to fully identify a given ECMWF seasonal forecast system (that's already the case with SEAS5)
      • Being 1-byte long doesn't seem appropriate
      • The definition for non-ECMWF data can be problematic (what numbering to use?)
    • The use of modelVersionDate (from section 4 templates 60,61) is not suitable:
      • the concept can be tricky to define
      • it is only present in templates 60,61 (so either the templates are repurposed to be used for both forecasts and hindcasts, or it woudn't be available for forecasts)


  • The use of MARS "method" is not a requirement, but it was introduced in the past to avoid significant performance degradation in MARS
    • Without "method" we would have some very sparse data hypercubes (the "annual" runs produce much fewer variables and members and it also has longer but less frequent steps).
      • Is this (or is this not) an issue anymore nowadays?
    • Note that future system designs (from ECMWF or others) can be even more complicated than the current ECMWF one (which has 12 start dates "7month-long", 4 start dates "13month-long")
    • A distinction between those different forecast ranges can be, though, useful for users


  • There is a strong preference to have GRIB keywords to encode "system", but there's still debate on the merits of "method" (possibly with different names, e.g. "range" instead of method)
    • A potential way forward was seen in having a section 4 template including those elements for both forecasts and hindcasts.
      • Keeping in that template modelVersionDate would help to properly label the ensemble member numbers for systems producing hindcasts on-the-fly which could need to cycle (produce the same members/start dates in different "production" years)


  • No labels