***** Draft ********

This page aims at documenting documents the steps to follow when a data provider plans to implement changes to their system, such as a new version of the model

Test data

First of all, the archive centres welcome to have some test data in advance, so the ingestion suites can be adapted.

Obviously, some changes are more disruptive than others:

...

their model or a change in the configuration.

There can be two types of changes:

...

...

In both cases, data providers must update the documentation with what has changed, so users are able to follow the history of a model

Changes to the configuration

When a change affects the number of fields, we ask data providers to:

• Notify in advance ECMWF and CMA,
• Provide test data (if required)
• Update the documentation.

Notify in advance ECMWF and CMA

• ECMWF
  • describe the change via ECMWF Service Desk form: https://www.ecmwf.int/en/about/contact-us
    • Subject:: select last option "Other"
    • Message: "system change for S2S archive"  + description of the change
  • it will result in creation of a Service Desk ticket which should be used in the following for all further communication (test data, docs update etc..)
• CMA: TBD

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 required.

For the second type of changes, we welcome to have test data in advance. This is achieved by naming files as test instead of prod, and by setting in the GRIB header Production status of data to 7: 

6: S2S operational products
7: S2S test products

Documentation

For the second type of changes, we need to adapt the Models page

Once you have a full cycle of test data (whether real-time and/or reforecast), contact  S2S support team for checking it.

Update the documentation

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)In the description of each individual model, we suggest to keep the previous description, with an indication of dates for which this configuration was valid, and create a new page with the new configuration. As an example, one can follow what has been done for ECMWF Model, which has changed several times.