...
| Info | ||
|---|---|---|
| ||
|
In both cases, data providers must documentupdate the documentation with what has changed, so users are able to follow the history of a model (see as an example the changes in ECMWF Model).
Changes to the configuration
When the a change affects the number of fields, we ask data providers to:
- Notify in advance ECMWF and CMA,
- Provide test data , and(if required)
- Update the Models summary pagedocumentation.
Notify in advance ECMWF and CMA
Send an e-mail to s2s.support@lists.ecmwf.int. describing the change.
Provide test data
...
(if required)
If the change affects how fields are encoded, it is recommended to test the new encoding by ingesting test data in the S2S database, so ECMWF and CMA could adapt the ingestion suites if requiredECMWF and CMA would like to have access to test data in advance, so the ingestion suites can be adapted.
This is achieved by naming files as test instead of prod, and by setting in the GRIB header Production status of data to 7:
...
Once you have a full cycle of test data (whether real-time and/or reforecast) we ask you to contact s2s.support@lists.ecmwf.int.
Update the documentation
This is usually Models are documented in two places:
- Models summary, which contains an overview of the latest configuration
- A page describing in detail each model (for example, changes in ECMWF Model), where one would keep details of previous configurations, in particular the date of the change.
For changes to the configuration for the same model (increase frequency, extend reforecast, addition of parameters), a note could be added to the model page (for example, see changes in UKMO Model)