Table of Contents |
---|
Model update handling
Follow instructions in Model update handling
Support checks (on provider's end)
Info |
---|
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.
Statistics
Support incidents
Number of operational incidents since August 2018
Year | 2018 | 2019 | 2020 | 2021 | 2022 | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Quarter | Q3 | Q4 | 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 |
updated | 10 | 14 | 21 | 8 | 12 | 17 | 58 | 22 | 17 | 16 | 21 | 76 | 12 | 12 | 13 | 7 | 44 | 17 | 7 | 17 | 15 | 56 |
closed | 5 | 7 | 21 | 8 | 9 | 11 | 49 | 17 | 15 | 10 | 15 | 57 | 9 | 10 | 11 | 4 | 34 | 12 | 7 | 7 | 10 | 36 |
- 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)
System changes
Number of operational system updates since 2019
Year | 2019 | 2020 | 2021 | 2022 |
---|---|---|---|---|
created/updated | 4 | 11 | 16 | 37* |
*impacted by the changes related to migration to Bologna
Show If | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||
Links to JIRASupport incidents overview
System changes overview
|