Model update handling
Follow instructions in Model update handling
Support checks (on provider's end)
| 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) |
|
|
|
|
|
|
|
|---|
CPTEC (sbsj) |
|
|
|
|
|
|
|
|
|---|
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 | 2023 | 2024 |
|---|
| 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 | 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 | | | | 6 | 38 | 12 | 12 | 10 |
|
|
|---|
| updated | 10 | 14 | 21 | 8 | 12 | 17 | 58 | 22 | 17 | 16 | 21 | 76 | 12 | 12 | 13 | 7 | 44 | 17 | 7 | 17 | 15 | 56 | | | | 18 | 59 | 15 | 15 | 15 |
|
|
|---|
| closed | 5 | 7 | 21 | 8 | 9 | 11 | 49 | 17 | 15 | 10 | 15 | 57 | 9 | 10 | 11 | 4 | 34 | 12 | 7 | 7 | 10 | 36 | | | | 8 | 38 | 18 | 21 | 10 |
|
|
|---|
|
Year | 2018 | 2019 | 2020 | 2021 | 2022 | 2023 | 2024 |
|---|
| 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 | 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 | | | | | 38 | | | |
|
|
|---|
| updated | 10 | 14 | 21 | 8 | 12 | 17 | 58 | 22 | 17 | 16 | 21 | 76 | 12 | 12 | 13 | 7 | 44 | 17 | 7 | 17 | 15 | 56 | | | | | 59 | | | |
|
|
|---|
| closed | 5 | 7 | 21 | 8 | 9 | 11 | 49 | 17 | 15 | 10 | 15 | 57 | 9 | 10 | 11 | 4 | 34 | 12 | 7 | 7 | 10 | 36 | | | | | 79 | | | |
|
|
|---|
|
- 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 | 2023 | 2024 |
|---|
| created/updated | 4 | 11 | 16 | 36* | | |
|---|
*impacted by migration to Bologna
Links to JIRASupport incidents overviewRestricted to user group "ecmwf" only. |
System changes overview
|