Contributors H. Konrad (DWD), N. Rahpoe (DWD), A. Mayer (DWD), A. C. Mikalsen (DWD), R. Hollmann (DWD)
Issued by: Deutscher Wetterdienst / H. Konrad
Date: 06/10/2020
Ref: C3S_D312b_Lot1.2.1.1-v1.0_201812_SQAD_ECVPrecipitation_GPCP_v1.0.1
Official reference number service contract: 2018/C3S_312b_Lot1_DWD/SC1
History of modifications
List of datasets covered by this document
Acronyms
General definitions
In the scope of the Copernicus Climate Change Service (C3S), a Climate Data Record (CDR) does always have a fixed end point in time, whereas an Interim Climate Data Record (ICDR) is extended continuously, often serving as an extension of a respective completed CDR.
In contrast to this, the record by the Global Precipitation Climatology Project (GPCP) is continuously extended in time, with a latency of two to three months due to the latency of the rain gauge product (see below). In order to avoid confusion, we state here that we will label the GPCP record as CDR in the scope of the brokering to C3S until December 2017, which is the end point for the first delivery to the CDS. Later extensions of the record will be labelled as ICDR in the scope of the brokering to C3S. In this sense, the term 'ICDR' is used here according to C3S terminology.
The GPCP provides an interim product for the monthly solutions, too. It is based on the same satellite data and respective algorithms, but lacks the input of the rain-gauge dataset (see below). Consequently, it is available much earlier than the fully processed data. When the rain-gauge dataset becomes available and the processing can be completed, the files containing the interim dataset are replaced by the fully processed ones. In the scope of the brokering the GPCP data to C3S, we choose not to broker the interim monthly data in order to avoid confusion and frequent updates. Users interested in these more up-to-date files are referred to the original data repositories (see below).
Please note: The version numbering within C3S (4th column in List of datasets on page 3) is for internal use and should not be used when citing the dataset.
Scope of the document
This document describes the systems used for delivering the satellite-based estimates of global precipitation by the Global Precipitation Climatology Project (GPCP) at the University of Maryland (UMD), brokered to the Climate Data Store (CDS) by the Copernicus Climate Change Service (C3S). Interfaces to external data and the interface to the CDS are outlined. Internal procedures for managing and communicating system maintenance and for user support are described.
Executive summary
Estimates of precipitation by the Global Precipitation Climatology Project (GPCP) from the University of Maryland (UMD) are brokered to the Climate Data Store (CDS) by the Copernicus Climate Change Service (C3S). The GPCP is part of the international World Climate Research Programme (WCRP) and its Global Energy and Water Exchanges (GEWEX) project. All intellectual property rights remain with the GPCP.
Within C3S the dataset is made accessible to the CDS via the webserver hosted by DWD (https://c3s.satproj.klima.dwd.de/data/) and can be ordered via HTTP protocol. Login details are provided to the CDS team via the entry in the Harmonised Table. Respective outages will be kept to a minimum and, whenever possible, communicated to C3S in advance. We provide user support for queries relating to our products when forwarded to us by C3S.
1. System overview
1.1 System elements and interfaces
The data product (GPCP) is brokered from external sources (UMD); only the interfaces relevant for the delivery to the CDS are relevant here.
1.1.1 Interfaces to external data
Brokered CDR and ICDR products
The original dataset is continuously downloaded from the GPCP repository, accessible through the GPCP landing page at the UMD, http://gpcp.umd.edu/.
1.1.2 Delivery of the data to C3S
The data are made accessible via DWD's webserver at https://c3s.satproj.klima.dwd.de/data/. All data provided for the CDS by DWD will be uploaded to this server. It can be accessed via HTTP protocol. Exact addresses of the provided files will be provided to the CDS upon submission. This allows automated access to the files, e.g. via scripts handling the delivery chain of an order in the CDS from the server to the user. We aim for a 99% availability of the data server, with 95% of the data transactions happening at a rate of 10 Mbit/s or faster.
1.2 Hardware, supercomputers and cloud computing
The GPCP datasets are produced outside the scope of C3S. Therefore, only storage and delivery is described here.
1.2.1 Back-up
The GPCP products are not backed up within the framework of C3S. In the case of data corruption or loss on the data server, which serves as interface to the CDS, it can be downloaded again from its original, dedicated source, where back-ups outside our responsibilities are maintained.
1.2.2 Webserver at DWD
DWD hosts the webserver (CentOs Linux) that can be accessed from outside the DWD firewall via HTTP. Monitoring of server availability is routinely performed using Nagios IT Infrastructure Monitoring Tool. The check is performed every 60 second and if the data on the webserver are unavailable, an automatic email notification is issued.
Preliminary analysis of the required disk space for data sets provided by DWD within C3S_312b_Lot1 necessary disk space shows that the quota on the data server dedicated to DWD's efforts within C3S_312b_Lot1 will not be exceeded.
2. Upgrade cycle implementation procedure
n/a
3. Procedures for reprocessing CDRs
n/a
4. System maintenance and system failures
In general, any issues with IT infrastructure that either delays delivery of data or impedes access to data via the CDS will be documented in the Quarterly Report.
4.1 Interfaces to external data
This section discusses treatment of delays at interfaces to external data sources.
4.1.1 Brokered CDRs and ICDRs
It is beyond the scope of our responsibility to safeguard the stability of services and data servers of external providers. If we become aware of issues at their end that will impede the timely delivery of brokered data, we will notify C3S.
4.2 Interface to the CDS
This section discusses maintenance and outages of the data server hosting the files for access through the CDS.
4.2.1 Planned maintenance
Planned outages of the data server on which the CDS accesses the files are kept to a minimum. However, software updates may become necessary, or hardware may need to be maintained or replaced. Such planned outages will be communicated to the CDS as early as possible. Respective notifications will be issued by DWD's IT department and delivered to the DWD-based members of the Service Management Team of C3S_312b_Lot1, who will ensure prompt passing on to the CDS. We do not expect to contact users of data sets submitted by us directly, but only through this communication to CDS.
We are open to requests by C3S to schedule dates on which no planned maintenance involving an outage should be carried out. Although a respective commitment by the IT department cannot be guaranteed, we always strive to respect such requests.
4.2.2 Unplanned outages
Unexpected system outages will be treated according to internal regulations and procedures at DWD's IT department. This involves notification of the DWD-based members of the Service Management Team, who will in turn notify C3S of the outage as quickly as possible. The IT department will resolve the issue according to their procedures and notify C3S, again via the Service Management Team.
5. User support
5.1 Enquiries
The user (customer) has the possibility to browse and search in the Copernicus Knowledge Base (CKB) (CAMS and C3S Knowledge Base (CKB)) or the Copernicus Climate Data Store desk (https://cds.climate.copernicus.eu/contact-us). This is known as the level-0 process of User Support.
Figure 1: The schematic of Copernicus User Support (Copernicus User Support Handbook, V2.1)
Contact and User Support process on JIRA service desk
If the level-0 support fails to answer the user's query, they may then make a request, which is sent to the Copernicus User Support (CUS) Service team at ECMWF. These (level-1) requests will be handled within 8 hours.
For any scientific and specialist enquiries that cannot be answered by the CUS team at ECMWF or addressed by the Copernicus Knowledge Base, the request will be forwarded to the Copernicus User Support Specialists (level-2).
Enquiries forwarded to the Copernicus User Support Specialist team will be acknowledged within 3 working days (target 100%) and a notification sent to the user. This step is handled on the JIRA 1 Service Desk established at ECMWF for the current project. In case of specific scientific issues, the enquiries will be channeled to the ECV and data specialist of the C3S2_312a_Lot1 project and should be resolved within 3 working weeks (target 85%). In case of brokered datasets, the data specialist may choose to contact the responsible team at the provider level if they cannot resolve the issue on their own. In each yearly quarter, we aim for User Support satisfaction scoring 3 in 90% of all voluntary based feedbacks by users, with 1 (very unsatisfied) to 5 (very satisfied). We will also list the number of tickets raised by users on the JIRA system in the Quarterly Report.
- JIRA: Project management software tool created by Atlassian company ↩
References
n/a
