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 was seen as appropriate
  • The distinction between section 4 templates 1,11 and 60,61 (the latter only add modelVersionDate) was considered 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 it 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 (to distinguish 7-month runs from 13-month runs) 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). 
    • Note that future ECMWF system designs can be even more complicated than the current one (currently 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 felling that we would need to have GRIB keywords to encode the following elements: "system", "method" (this one could be called "range" or something similar)
  
  • 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)