1.1. Model update handling
Follow instructions in Model update handling
1.2. Support checks (on provider's end)
Read in Recommended support checks about practises used at ECMWF. Some examples and source codes are also available there.
| Organization | Data acquisition method | Data transfer check | Data delay check | Data completeness check | Data quality check | * Data packing | Data recovery option | |
|---|---|---|---|---|---|---|---|---|
| Exists? | Time limit? | |||||||
BoM (ammc) | FTP | |||||||
CMA (babj) | FTP | |||||||
| CNR-ISAC (isac) | HTTP | |||||||
CNRM (lfpw) | ECPDS (ECGATE) | |||||||
ECCC (cwao) | SFTP | |||||||
ECMWF (ecmf) | MARS retrieval | N/A | YES | YES | YES | YES | NO | |
HMCR (rums) | FTP | NO | YES | YES | NO | |||
| IAP-CAS (anso) | FTP | |||||||
| JMA (rjtd) | HTTP | |||||||
KMA (rksl) | ECPDS (push) | YES | NO | YES | NO | YES | NO | |
| NCEP (kwbc) | FTP | YES | YES | YES | NO | |||
| UKMO (egrr) | ECPDS (push) | YES | YES | NO | NO | NO | ||
- Data acquisition method: Acquisition method is pull (via ECPDS/FTP) from the provider's location to ECMWF's premises if not specified
- Data transfer check: Is the data transfer checked to avoid any technical issues on the way from provider's location to ECMWF's premises? Was the data delivered bit identical?
- Data delay check: Is the potential delay of data availability checked on the provider's side?
- Data completeness check: Is the data content (number of expected fields; reference field list etc) checked on the provider's side?
- Data quality check: Is there any data quality control to avoid e.g. unrealistic parameter values due to interpolation or any other kind of error either scientific or technical?
- Data packing: only if differs from the required single packing
- Data recovery option: Is it possible to recover any missing/corrupted data when needed?
- If yes, is there any time limit when the data can be rescued ? If yes, specify number of days within which the recovery action must happen.
1.3. Statistics
1.3.1. Support incidents
Number of operational incidents since August 2018
Year | 2018 | 2019 | 2020 | 2021 | 2022 | 2023 | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Quarter | Q3 | Q4 | Q1 | Q2 | Q3 | Q4 | sum | Q1 | Q2 | Q3 | Q4 | sum | Q1 | Q2 | Q3 | Q4 | sum | Q1 | Q2 | Q3 | Q4 | sum | Q1 | Q2 | Q3 | Q4 | sum |
created | 10 | 11 | 12 | 7 | 10 | 14 | 43 | 17 | 15 | 11 | 14 | 57 | 6 | 9 | 10 | 4 | 29 | 13 | 4 | 16 | 13 | 46 | 9 | 7 | 12 | ||
| updated | 10 | 14 | 21 | 8 | 12 | 17 | 58 | 22 | 17 | 16 | 21 | 76 | 12 | 12 | 13 | 7 | 44 | 17 | 7 | 17 | 15 | 56 | 13 | 10 | 15 | ||
| closed | 5 | 7 | 21 | 8 | 9 | 11 | 49 | 17 | 15 | 10 | 15 | 57 | 9 | 10 | 11 | 4 | 34 | 12 | 7 | 7 | 10 | 36 | 14 | 22 | 12 | ||
- Number of updated incidents includes the newly created or closed ones
- Updated or closed incidents may refer to those from previous quarters
- Stats do not include system change tickets (=non-incidents)
1.3.2. System changes
Number of operational system updates since 2019
Year | 2019 | 2020 | 2021 | 2022 | 2023 |
|---|---|---|---|---|---|
| created/updated | 4 | 11 | 16 | 36* | 14** |
*impacted by migration to Bologna
**until 9/2023