View Source

Read in Recommended support checks about hopefully helpful practises used at ECMWF which can be shared. Some examples and source codes are also available there.

Support checks (on provider's end)

Organisation	Data acquisition method	Data transfer check	Data delay check	Data completeness check	Data quality check	Not simple packing?	Data recovery option
Organisation	Data acquisition method	Data transfer check	Data delay check	Data completeness check	Data quality check	Not simple packing?	Exists?	Time limit?
CMA (babj)	ftp
CPTEC (sbsj)	http
DWD (edzw)	sftp
ECCC (cwao)	sftp (ssh key)	YES	YES			YES
ECMWF (ecmf)	MARS retrieval	N/A	YES	YES	YES		YES	NO
IMD (vabb)	ftp	YES	YES	YES	NO		YES	NO
JMA (rjtd)	http
KMA (rksl)	push (dedicated line via ECPDS)	YES (?)	NO	YES	NO
MF (lfpw)	push (dedicated line via ECPDS)					YES
UKMO (egrr)	copy from ecgb
NCEP (kwbc)	ftp
NCMRWF (dems)	ftp	YES	YES	YES	NO		YES	NO

Data acquisition method: If not specified the data retrieval method is pull by ECMWF's acquisition system ECPDS from the provider's location
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?
Not simple packing? The data should be packed using GRIB simple packing for faster processing by users (HW packing is used to archive the data)
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 May 2018

Year	2018			2019				2020
Quarter	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4
created	3	18	23	15	22	16	16	12	14	31
updated	3	19	29	19	26	17	21	26	19	35
closed	2	12	23	19	24	14	14	18	17	21

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
created/updated	4	6

Links to JIRA

Restricted to user group "ecmwf" only.

Support checks (on provider's end)

Statistics

Support incidents

System changes

Links to JIRA

Support incidents overview

System changes overview