...
- 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 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 generatingProcessIdentifier (bit 14 from section 4 templates) can be problematic:
- The use of MARS method (to distinguish 7-month runs from 13-month runs) "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 ECMWF system designs (from ECMWF or others) can be even more complicated than the current ECMWF one (currently 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
- 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).
- There is a strong felling that we would need preference to have GRIB keywords to encode the following elements: "system", but there's still debate on the merits of "method" (this one could be called possibly with different names, e.g. "range" or something similarinstead 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)
- A potential way forward was seen in having a section 4 template including those elements for both forecasts and hindcasts.
...