Contributors: G.E. Thomas (UKRI-STFC RAL Space)
Issued by: STFC RAL Space (UKRI-STFC) / Gareth Thomas
Date: 26/01/2023
Ref: C3S2_D312a_Lot1.2.1.3-v4.0_202301_ATBD_CCICloudProperties_v1.2
Official reference number service contract: 2021/C3S2_312a_Lot1_DWD/SC1
History of modifications
List of datasets covered by this document
Related documents
Acronyms
List of tables
List of figures
General definitions
Table 1: Summary of variables and definitions
Variables | Abbreviation | Definition |
Cloud mask / Cloud fraction | CMA/ CFC | A binary cloud mask per pixel (L2) and from there derived monthly total cloud fractional coverage (L3C) |
Cloud optical thickness | COT | The line integral of the absorption extinction coefficient (at 0.55μm wavelength) along the vertical in cloudy pixels. |
Cloud effective radius | CER | The area-weighted radius of the cloud droplet and crystal particles, respectively. |
Cloud top pressure/ height/ temperature | CTP/ CTH/ CTT
| The air pressure [hPa] /height [m] /temperature [K] of the uppermost cloud layer that could be identified by the retrieval system. |
Cloud liquid water path/ Ice water path
| LWP/ IWP
| The vertical integrated liquid/ice water content of existing cloud layers; derived from CER and COT. LWP and IWP together represent the cloud water path (CWP) |
Table 2: Definition of processing levels
Processing level | Definition |
Level-1b | The full-resolution geolocated radiometric measurements (for each view and each channel), rebinned onto a regular spatial grid. |
Level-2 (L2) | Retrieved cloud variables at full input data resolution, thus with the same resolution and location as the sensor measurements (Level-1b). |
Level-3C (L3C) | Cloud properties of Level-2 orbits of one single sensor combined (averaged) on a global spatial grid. Both daily and monthly products provided through C3S are Level-3C. |
Table 3: Definition of various technical terms used in the document
Jargon | Definition |
Brokered product | The C3S Climate Data Store (CDS) provides both data produced specifically for C3S and so-called brokered products. The latter are existing products produced under an independent programme or project which are made available through the CDS. |
Climate Data Store (CDS) | The front-end and delivery mechanism for data made available through C3S. |
Near-real-time (NRT) | Data which is provided within a short time window (often taken to be three hours, but there is no fixed definition) of the measurement. NRT data is often supplanted by a subsequent data stream, which is subject to more rigorous checking of data quality. |
Radiative transfer | The mathematical modelling of the interaction of electromagnetic radiation with some medium – in this case solar and thermal-infrared radiation passing through the Earth’s atmosphere. |
Retrieval | A numerical data analysis scheme which uses some form of mathematical inversion to derive physical properties from some form of measurement. In this case, the derivation of cloud properties from satellite measured radiances. |
Forward model | A deterministic model which predicts the measurements made of a system, given its physical properties. The forward model is the function which is mathematically inverted by a retrieval scheme. In this case, the forward model predicts the radiances measured by a satellite instrument as a function of atmospheric and surface state, and cloud properties. |
TCDR | It is a consistently-processed time series of a geophysical variable of sufficient length and quality. |
ICDR | An Interim Climate Data Record (ICDR) denotes an extension of TCDR, processed with a processing system as consistent as possible to the generation of TCDR. |
CDR | A Climate Data Record (CDR) is defined as a time series of measurements with sufficient length, consistency, and continuity to determine climate variability and change. |
Scope of the document
This Algorithm Theoretical Basis Document (ATBD) is associated with the CDS catalogue entry: Cloud properties global gridded monthly and daily data from 1982 to present derived from satellite observations. The ATBD describes the algorithms used to generate the Climate Data Record (CDR) on Cloud Properties brokered from the European Space Agency Cloud Climate Change Initiative (ESA’s Cloud_cci) programme and its extension with an interim-CDR (ICDR) derived from the Sea and Land Surface Temperature Radiometer (SLSTR) on the Sentinel-3 platform.
This extension is generated specifically for the Copernicus Climate Change Service (C3S) by RAL Space, which is part of the UK’s Science and Technology Facilities Council’s (STFC), based at the Rutherford Appleton Laboratory (RAL), following the same algorithm and processing chain developed under the ESA’s Cloud_cci. Therefore, this document refers to several Cloud_cci documents (see Related documents), namely the ESA Cloud_cci ATBDs [D1, D2], the ESA Cloud_cci Product User Guide (PUG) [D3], and the ESA Cloud_cci Error characterization report [D4], with additional information specific to SLSTR included. These documents describe the data processing chain and the algorithms used to generate the CDR products. The assessment described in this document is carried out within the scope of C3S and the intellectual property rights of the products themselves remain with Cloud_cci, in the case of the CDR, or lie with STFC RAL Space, in the case of the ICDR. This document is not part of the official Cloud_cci documentation but produced solely in the scope of the brokering to the CDS.
Executive summary
The CDR on cloud properties is a product of the CC4CL dataset produced by ESA’s Cloud_cci project and brokered to C3S, and the SLSTR ICDR is an extension to the brokered product. Accordingly, this document largely refers to the ESA Cloud_cci documentation.
The Cloud_cci record contains 17 years (1995-2012) of satellite-borne observations derived from measurements of the Along Track Scanning Radiometer (ATSR) series of satellites on board the ESA 2nd Environmental Research Satellite (ERS-2) and ENVISAT satellites. The CDR provided to C3S comprises daily (0.1° x 0.1° resolution), and monthly (0.5° x 0.5° resolution) means of cloud properties on a regular global latitude-longitude grid. The SLSTR ICDR continues this record, with a 5-year gap, with version v3.x providing cloud products from Sentinel-3A SLSTR from 2017 onwards, and from Sentinel-3B from late 2018 onwards, when data from each platform became available. Cloud properties products are provided individually from each Sentinel-3 platform, and as a combined product that averages data from both SLSTR instruments into single daily and monthly means.
The provided cloud products are cloud fractional cover, cloud top level (consisting of cloud top temperature, pressure, and height), and cloud physical properties (consisting of cloud optical thickness, effective radius, and water path for both the liquid and the ice phase). Note that the brokered service within Copernicus provides only a subset of the original CCI cloud properties dataset, thus the mentioned products do not cover the entire range on cloud products contained in the original dataset provided by Cloud_cci.
This document is divided into the following sections described below:
- Instruments Describes the characteristics of the instruments and satellite platforms used to produce the data which make up the primary input to the cloud-properties processing chain. This amounts to a general description of the measurements used as the primary inputs for the analysis, including the spectral bands used, spatial and temporal resolution and coverage.
- Input and auxiliary data This section specifies the particular data products used as inputs to the cloud-properties CDR processing chain. This includes both the primary input “fundamental climate data record” and the various ancillary data also required by the processing chain.
- Algorithms Describes the algorithms which constitute the cloud-properties processing chain. These include the retrieval scheme, which derives level-2 cloud-properties from the top-of-atmosphere radiances measured by satellite instruments, and the level-3 processing, which averages the level-2 data onto defined latitude-longitude grids to produce the daily and monthly products provided by C3S. A description of uncertainty characterization is also included in this section.
- Output data Describes the format and content of the output files which constitute the cloud-properties CDR provided by C3S.
1. Instruments
The brokered Cloud_cci cloud dataset is derived from the ATSR-2 and AATSR instruments, which are described in Cloud_cci ATBD [D1], Section 2.2. ATSR-2 flew on board the second European Research Satellite (ERS-2), which provide global data coverage from mid-1995 until mid-2003, while AATSR flew on ENVISAT from mid-2002 until April 2012 (see Figure 1‑2). Both satellites were in Sun-synchronous polar orbits, with ENVISAT following the same ground-track as ERS-2, but with an overpass time 30 minutes ahead. A summary of the orbital characteristics of ERS-2 and ENVISAT are given in Table 1‑1. ATSR-2 and (A)ATSR were essentially identical instruments, with the same set of channels providing the same 1×1 km nominal spatial resolution and 512 km wide swath. The unique feature of the ATSR instruments was their dual-view measurement system (see Figure 1-1). The instruments used a spinning mirror to produce a conical scan pattern, in which the instrument views both directly down (the nadir-view) and in the direction of the satellite’s orbital path, centred at a zenith angle of 55° (the forward-view). The dual-view is key to the accuracy of the ATSR instruments in their primary role of measuring sea surface temperature and is also very useful for other applications, such as making measurements of atmospheric aerosol. However, for the determination of cloud properties, only the nadir-view is used. Another key feature of the ATSR instruments was their high accuracy. During every sweep of the conical scan pattern, the instrument views two on-board temperature controlled back-body targets, which provide on-going calibration of the thermal channels. Additionally, the instrument views the sun through an opal filter once per-orbit, which provides shortwave channel calibration.
Figure 1‑1: (A)ATSR dual-view scanning system.
One significant difference between the two instruments is that ERS-2 did not provide enough communication bandwidth for all ATSR-2 data to be fully downlinked. This limitation is dealt with by two data-saving data modes:
- The so-called “narrow-swath” mode, whereby only the centre 256 pixels of the swath are available for 1 or more shortwave channels. This mode was only active over the ocean and the 550 nm channel-1 is the most often effected.
- Additionally, the number of bits used to encode the radiance measured by some shortwave channels is sometimes lowered to 8 from the nominal 12. Again, this only occurs over the ocean.
Table 1‑1: The specifications of the (A)ATSR instruments.
| Capability | (A)ATSR Specifications |
Swath | Nadir view | 512 km |
Oblique view | 512 km | |
Global Coverage Revisit Times | 3-4 day (mean) | |
Spatial Sampling interval at Sub-satellite point (km) | VIS-SWIR | 1 km |
IR | 1 km | |
Spectral channel centre (µm) | VIS | 0.554 (Ch1); 0.659 (Ch2) 0.865 (Ch3) |
SWIR | 1.61 (Ch4) | |
MWIR/TIR | 3.70 (Ch5); 10.85 (Ch6); 12.00 (Ch7) |
Figure 1‑2: Time coverage of ATSR-2, AATSR and SLSTR at the time of writing.
ICDR data is derived from the Sea and Land Surface Temperature Radiometer (SLSTR), flown on board the Copernicus Sentinel-3 platform. The SLSTR is an improved version of the ATSR instruments, providing additional spectral channels, improved spatial resolution for the visible and shortwave-infrared channels and a considerably wider swath (1,400 km nadir swath, compared to 512 km for AATSR). Otherwise, SLSTR maintains the main features of the ATSR series; namely the dual-view and on-board calibration systems. As part of the Copernicus operational observation system, two SLSTR instruments are kept operational, with a backup instrument also to be in orbit (although not yet launched). The two operational instruments were launched on Sentinel-3A on 16th February 2016 and Sentinel-3B on 25th April 2018. The two platforms fly in identical, interleaved sun-synchronous orbits, such that the two SLSTR instruments provide nearly global coverage twice daily (with one day and one night overpass). Orbital characteristics of Sentinel-3A are summarised in Table 1-2.
Table 1‑2: The orbital characteristics of the Sentinel-3 satellites. Note that these characteristics are very similar to the ERS-2 and ENVISAT platforms which carried the preceding ATSR instruments.
Platform | Altitude (km) | Inclination | Period (min) | Repeat Cycle (days) | Ground-track deviation | Local Time at Descending node |
ERS-2 | 780 | 98.5° | 100 | 35 | 10:30 | |
ENVISAT | 799.8 | 98.55° | 100.59 | 35 | 10:00 | |
Sentinel-3 | 814.5 | 98.65° | 100.99 | 27 | ±1 km | 10:00 |
The SLSTR instrument is described in detail by the Sentinel-3 SLSTR User Guide (see References), but an overview of its specifications is given in Table 1-3.
Table 1‑3: The specifications of the SLSTR instruments (taken from the SLSTR User Guide (see References)).
| Capability | SLSTR Specifications |
Swath | Nadir view | 1,400 km |
Oblique view | 740 km | |
Global Coverage Revisit Times (nadir view) | 1 satellite | 1 day (mean) |
2 satellites | 0.5 day (mean) | |
Spatial Sampling interval at Sub-satellite point (km) | VIS-SWIR | 0.5 km |
IR-Fire | 1 km | |
Spectral channel centre (µm) | VIS | 0.554 (S1); 0.659 (S2) 0.868 (S3) |
SWIR | 1.374 (S4); 1.613 (S5); 2.25 (S6) | |
MWIR/TIR | 3.742 (S7); 10.85 (S8); 12.02 (S9) | |
Fire ½ | 3.742 (F1); 10.85 (F2) | |
Radiometric Resolution | VIS (Albedo =0.5%) | Signal-to-Noise Ratio (SNR) > 20 |
SWIR (Albedo =0.5%) | Signal-to-Noise Ratio (SNR) > 20 | |
MWIR (T =270K) | NEΔT < 80 mK | |
TIR (T=270K) | NEΔT < 50 mK | |
Fire 1 (<500 K) | NEΔT < 1 K | |
Fire 2 (<400 K) | NEΔT < 0.5 K | |
Radiometric Accuracy | VIS-SWIR (Albedo = 2-100%) | < 2% (Beginning of Life) |
<5% (End of Life) | ||
MWIR –TIR | < 0.2 K (0.1 K goal) | |
Fire (< 500 K) | < 3 K |
2. Input and auxiliary data
This section summarises the required input data used in the retrieval algorithms
2.1 Fundamental climate data record
The input data source for the Cloud_cci dataset is the so-called AATSR-multi-mission level 1b data record, and this forms the fundamental climate data record for this product. The processing of measured radiances to level 1b is described in the ESA AATSR Detailed Processing Model Level 1b (see References) and ENVISAT-style products for ATSR-1 and ATSR-2 data (see References) documents.
The input data source for the SLSTR ICDR is the (non near-real-time) ESA Observation mode SLSTR level-1 archive, hosted by the Centre for Environmental Data Analysis (CEDA). At time of writing, no complete reprocessing of the SLSTR level-1 archive has been undertaken, and improvements in instrument calibration, pixel colocation/geolocation and minor product details have continued to evolve throughout the lifetime of the mission. It is likely that some variation in cloud product quality will be attributable to this inconsistency in the level-1 input data. Details of the quality of SLSTR data can be found in the “Data Product Quality Reports” section of the SLSTR User Guide (see References).
SLSTR level-1 data is provided in NetCDF-4 formatted files, which are segregated into 3-minute frames. The level-1 data provide:
- Top of Atmosphere (TOA) reflectance (for visible and shortwave infrared (SWIR) channels)
- Brightness temperature (for thermal infrared (TIR) channels)
- Pixel viewing geometry
- Measurement time
- Geolocation for each pixel
as well as other auxiliary information (see the SLSTR User Guide (see References) for further details).
The specific spectral channels used in producing the (A)ASTR and SLSTR cloud properties datasets are detailed in Table 2‑1, which were chosen to match the so-called heritage-channels provided by the long-running AVHRR instrument series1. The cloud retrieval only makes use of the nadir view of the (A)ATSR and SLSTR instruments.
Table 2‑1: (A)ATSR and SLSTR channels used to produce the Cloud_cci cloud properties v3.0 TCDR and SLSTR v3.x ICDR
(A)ATSR Channel number | SLSTR Band name | Nominal wavelength |
2 | S2 | 0.67 μm |
3 | S3 | 0.87 μm |
4 | S5 | 1.6 μm |
6 | S8 | 10.8 μm |
7 | S9 | 12.0 μm |
2.2 Specific input and auxiliary data
In addition to (A)ATSR or SLSTR level 1 data, the CC4CL retrieval scheme also relies on a range of auxiliary datasets, which are detailed in Table 2‑2. These data provide information needed by the analysis which cannot be determined from the satellite radiance measurements that form the main input of the algorithm. For instance, knowledge of the atmospheric pressure and temperature profiles allow the conversion of cloud-top temperature (to which the satellite radiances are sensitive) to cloud-top pressure and height. Knowledge of surface properties improve the bottom-of-atmosphere constraint to the radiative transfer carried out in the analysis. The RTTOV package, which provides the clear-sky radiative transfer for the retrieval, has its own set of input files.
Table 2‑2: Auxiliary data used in generating the Cloud_cci TCDR and SLSTR ICDR cloud properties products.
Dataset | Description |
ECMWF ERA-Interim | ECMWF reanalysis products provide pressure, temperature, humidity and ozone profiles, as well a priori surface temperature, sea ice extent and near-surface wind speed for ocean surface reflectance calculation. |
MODIS MCD43A12 V006 | The MODIS BRDF product provides land-surface reflectance. |
IREMIS UW Baseline Fit | The Global Infrared Land Surface Emissivity (IREMIS) University of Wisconsin-Madison Baseline Fit to the MODIS MOD11 emissivity product provides land-surface emissivity. |
RTTOV | The standard coefficient and database files provided with RTTOV v 12.1 are used, where not superseded by other auxiliary data (as is the case with the emissivity and surface reflectance atlases) |
Further details of the input and auxiliary data used are provided in the Cloud_cci CC4CL ATBD [D2], Section 3.
3. Algorithms
This section describes the algorithms used to derive the final cloud properties products. The overall processing scheme used to produce the CDR products, is known as the “Community Cloud for Climate” scheme or CC4CL, includes several processing steps:
- Pre-processing, which involves ingestion of input and auxiliary data, cloud masking, and performing clear-sky radiative transfer using the RTTOV package.
- Cloud-properties retrieval on pixels identified as cloud during pre-processing, using the Optimal Retrieval of Aerosol and Cloud (ORAC) algorithm. For (A)ATSR and SLSTR processing this step is run twice, once assuming the presence of liquid-water cloud and once assuming ice cloud.
- The combination of the two separate ORAC outputs into a single level-2 cloud product, which each pixel defined as either clear-sky, liquid-water cloud or ice cloud (noting that, in this context, clear-sky means any pixel determined not to contain water cloud).
- The compositing of the level-2 products into level-3c, containing daily or monthly averaged cloud properties on a regular latitude-longitude grid.
Each of these steps will be briefly summarized below, with references to existing documents which describe the scheme in detail.
Note that the scheme applied to the (A)ATSR CDR and SLSTR ICDR products is virtually identical. The only differences relate to the mechanics of reading the different ENVISAT and Copernicus style level-1b products, and handling the different specific instrument and platform names.
3.1 Pre-processing
The ORAC processor is designed as a general-purpose cloud and aerosol retrieval scheme, which can be applied relatively straight-forwardly to a wide range of visible-infra satellite imaging instruments. To facilitate this flexibility, ORAC is coupled with a pre-processor, which deals with the differences in instrument characteristics, data formats and auxiliary data and presents the retrieval scheme with a set of standard input files. The details of the pre-processing can be found in the Cloud_cci ATBD [D1], Sections 2-3 and the CC4CL ATBD [D2]. Here we provide an outline of the steps involved:
- The pre-processor is provided with a level-1b product of a support instrument. This data is read in, from which the location and time of measurement is determined, in addition to the radiance, reflectance and/or brightness temperature data, viewing geometry and other information required by the retrieval scheme.
- Ancillary data is then read in for the correct location and time. This includes reanalysis data for the atmospheric state (ECMWF ERA5 in this case) and data on surface properties, including land-surface emissivity and reflectance, ocean colour and ice/snow cover. In the case of land emissivity, reflectance and ocean colour, climatological data are used if data is unavailable for the specific time and location.
- Cloud detection and masking is performed. This set is described in more detail in Section 1.
- The surface bidirectional reflectance, along with hemispherical and bi-hemispherical reflectance, is estimated for each level-1b pixel. This is based on the ancillary surface reflectance data for land. Over water an ocean surface reflectance model, which is driven by near-surface wind vectors from reanalysis data combined with ocean colour data is used.
- Clear-sky (i.e. representing the atmosphere in the absence of cloud) radiative transfer is calculated by RTTOV for the area covered by the level-1b data, using the reanalysis data as input. This produces estimates of atmospheric transmission and emissivity above and below each layer within the atmospheric profile provided by the reanalysis, for each instrument channel and at the viewing geometry defined by the level-1b data.
- The level-1b radiances, processed ancillary data and RTTOV output are output as a standard set of NetCDF format files, which are independent of the instrument being used and the source of ancillary data, and form the input of the retrieval process itself.
3.2 Retrieval of swath-based cloud properties (level-2 data)
3.2.1 Cloud fractional cover
The algorithm used to retrieve the level-2 data on the cloud fractional cover is briefly summarised in Cloud_cci ATBD [D1] Section 3.1 and the CC4CL ATBD [D2] Section 2.1. A comprehensive description can be found in Sus et al. 2017.
Cloud masking is performed on level-1b radiances and is based on an artificial neural network (ANN) that has been trained using AVHRR-NOAA-19 measurements and collocated with CALIOP. As most satellite instruments do not provide suitable colocations with CALIOP due to orbital differences (AATSR and SLSTR are only offer colocations in a small band at high-latitudes, for instance), the cloud masking includes a step of adjusting the radiances observed by the target instrument in the heritage channels to best simulate the spectral response of AVHRR-NOAA-19. The coefficients used to perform this adjustment are calculated by convolving the heritage channel spectral response functions of the target instrument and NOAA-19.
The level-2 cloud mask is used to determine which level-1 pixels have the cloud properties retrieval algorithm applied and are used to derive the total cloud fractional coverage in the daily and monthly level-3c CDR products.
3.2.2 Cloud physical properties
The algorithm used to retrieve the level-2 data on the cloud physical properties (COT, CER, CTP, from which CTH, CTT, LWP and IWP are derived) is briefly summarised in the Cloud_cci ATBD [D1], Section 3.3. Detailed descriptions can be found in the CC4CL ATBD [D2] and McGarragh et al 2017.
The ORAC retrieval is an implementation of the optimal estimation (OE) technique, detailed by Rodgers (2000), and can be used to determine both aerosol and cloud properties from visible/infrared satellite radiometers. OE is derived from a Bayesian statistics approach and, formally, maximises the conditional probability of the state, , with respect to the measurement vector, y, and a priori estimate of the state, \( \bf x_a \) \( P(x |\bf y, x_a ) \) . Here the elements of the state vector consist of the retrieved parameters: log10 of cloud optical depth, cloud effective radius, cloud-top pressure, and surface temperature (other parameters, such as cloud-top height and water path are derived from these four). The measurement vector consists of the satellite observed radiances and brightness temperatures for each measurement channel. The vector \( \bf x_a \) consists of prior estimates of the state parameter – in this case these are set to climatological mean values for the cloud parameters and the ERA5 surface temperature.
Through the assumption that uncertainty in the measurement and a priori state parameters are normally distributed with a mean of zero (i.e. there are no systematic biases),
\( P(x |\bf y, x_a ) \)
is maximised by finding the minimum of the cost function:
\( J(f{x}) = [f(x)-y]S_y^{-1}[f(x)-y]^T+[x-x_a]S_a^{-1}[x-x_a]^T \quad (Eq. 1) \)
In this equation, Sy and Sa are the covariance matrices of the measurement vector and a priori state vector, respectively. In this case, both of these covariance matrices are assumed to be diagonal (implying that uncertainties in the measurements and priori state are not correlated). In the case of the a priori covariance, values of 108 are assumed for optical-depth, effective radius and cloud-top pressure (i.e. the a priori provides no practical constraint on the retrieval) while the surface temperature variance is set to 4 K2 over the sea and 25 K2 over land (an uncertainty of 2 K and 5 K respectively).
The vector f(x) in
\( J(x) = [f(x)-y]S_y^{-1}[f(x)-y]^T+[x-x_a]S_a^{-1}[x-x_a]^T \quad (Eq. 2) \)
is known as the forward model, which predicts the measurement, y, based on the value of the state, x. ORAC models cloud as a thin scattering (plus absorbing and emitting) layer imbedded in a clear atmosphere (in which gaseous absorption and Rayleigh scattering are modelled). The model assumes a plane-parallel atmosphere, which is assumed to be homogeneous on the scale of the instrument pixels. The forward model consists of two separate expressions, one of which calculates the top-of-atmosphere reflectance,
\( R_{TOA} \)
, (for channels which are sensitive to reflected solar radiation), while the other calculates top-of-atmosphere brightness temperature,
\( L^{\uparrow} (\theta_v) \)
(for thermal-infrared channels):
\( R_{TOA} = \tau_{ac}(\theta_0)\tau_{ac}(\theta_v)(R_{bb}(\theta_0,\theta_v,\phi) + \tau_{bc}(\theta_0)T^{\downarrow}_{bb}(\theta_0)\rho_{bb}(\theta_0,\theta_v,\phi)T^{\uparrow}_{bb}(\theta_v)\tau_{bc}(\theta_v) + \tau_{bc}(\theta_0)T^{\downarrow}_{bd}(\theta_0)\rho_{db}(\theta_v)T^{\downarrow}_{bb}(\theta_v)\tau_{bc}(\theta_v) + \)
\( \frac{(\tau_{bc}(\theta_0)T^{\downarrow}_{bb}(\theta_0)\rho_{bd}(\theta_0) + \tau_{bc}(\theta_0)T^{\downarrow}_{bd}(\theta_0)\rho_{dd}) + (T^{\uparrow}_{db}(\theta_v)\tau_{bc}(\theta_v) + R_{dd}\tau^{2}_{bc,d}\rho_{db}(\theta_v)T^{\uparrow}_{bb}(\theta_v)\tau_{bc}(\theta_v))}{1-\rho_{dd}R_{dd}\tau^{2}_{bc,d}}) \quad (Eq. 3) \)
and \( L^{\uparrow} (\theta_v) = L^{\uparrow}_{ac} + [L^{\downarrow}_{ac}R_{db}(\theta_v)+B(T-c) \epsilon (\theta_v) + L^{\uparrow}_{bc}(T_s)T^{\uparrow}_{db}(\theta_v)] \tau_{ac}(\theta_v) \quad (Eq. 4) \)
The symbols in Equations (3) and (4) are defined in Table 3-1.
Table 3-1: Symbols used in the forward model expressions
\[ \theta_0, \theta_v, \varphi \]
| The solar-zenith, satellite-zenith and relative azimuth angles, respectively. Used to denote the angular dependence of terms in the forward model expressions. |
\[ \uparrow \downarrow \]
| Used to denote the direction of radiative propagation. Eg. \( T^{\downarrow}_{bb}(\theta_0) \) denotes the downwelling transmission of the solar beam. |
\[ \tau_{ac}, \tau_{bc}, \tau_{bc,d} \]
| The above-cloud (ac) and below-cloud (bc) transmittances of the atmosphere for each instrument channel, as calculated by RTTOV in the pre-processing stage of the analysis. The additional “d” subscript denotes diffuse rather than direct-beam transmission. |
\[ T_{bb},T_{bd}, T_{db} \]
| \( T_{bb} \) and \( T_{db} \) direct and diffuse transmittance of the cloud layer for each instrument channel. The term \( T_{db} \) is the transmission of diffuse irradiance into a particular viewing direction; \( T_{bd} = T_{db} \) for equal illumination and viewing angles. Values of these parameters are calculated offline for a range of COT and CER values, which are tabulated in lookup-tables (LUTs). |
\[ R_{bb},R_{db}, R_{dd} \]
| These quantities are the bi-directional, hemispherical and bi-hemispherical reflectances of the cloud layer, for each instrument channel. As with the cloud transmittances, these parameters are tabulated offline and provided as LUTs to the retrieval. |
\[ \rho_{bb}, \rho_{bd}, \rho_{db}, \rho_{dd} \]
| The bi-directional, hemispherical (at the illumination and viewing angles) and bi-hemispherical reflectances of the surface, for each channel. ρ_bd and ρ_db are both hemispherical reflectances, with the former denoting the diffuse reflectance of the incoming solar-beam, while the later denotes the reflectance of diffuse downwelling into the viewing direction. |
\[ L_{ac}, L_{bc}(T_s) \]
| The atmospheric radiance (from thermal emission), for each instrument channel, from the atmosphere above and below the cloud layer respectively. \( L_{bc}(T_{s}) \) is also a function of surface temperature, \( T_{s} \) . See McGarragh et al 2017 \( T_{s} \) in the forward model. |
\[ B(T_c) \]
| The Planck function, as a function of cloud-top temperature ( \( T_{c} \) ), for each instrument channel. |
\[ \epsilon \]
| The effective cloud emissivity (as a function of the cloud properties), for each instrument channel. This is also provided by LUTs of offline calculations. |
As mentioned in Table 3-1, the values for cloud transmission, reflectance and emissivity are calculated offline for a range of cloud properties and tabulated as a function of cloud optical depth (COT) and cloud effective radius (CER). These calculations are done using the Discrete Ordinates (DISORT) radiative transfer code (see Stamnes et al. (1988)). The cloud-top pressure (CTP) is a function of the position of the cloud layer within the atmosphere.
The retrieval process is then a matter of minimising Equation (1) by varying the state parameters COT, CER, CTP and Ts. This is done using the standard Levenberg-Marquardt numerical optimisation technique (see Rodgers (2000)).
3.3 Error budget estimates
Error propagation is an integral component of the optimal estimation techniques employed by the ORAC retrieval, and provides uncertainties on all retrieved parameters, and parameters derived directly from them, at level-2. The handling of uncertainty for the cloud-mask, which is not part of the optimal estimation system, is dealt with separately.
The CC4CL processing scheme also includes comprehensive error propagation from level-2 to level-3 products. Details of uncertainty characterisation are referenced in the following sections.
3.3.1 Cloud fractional cover
Error budget estimates of cloud fractional cover as well as assumptions and limitations associated with the retrieval algorithms are found in the Cloud_cci Comprehensive Error Characterisation Report [D4].
3.3.2 Cloud physical properties
Error budget estimates of cloud physical properties as well as assumptions and limitations associated with the retrieval algorithms are found in the Cloud_cci CC4CL ATBD [D2] Section 2 and the Comprehensive Error Characterisation Report [D4].
3.4 Generation of final products (level-3 data)
The generation of the final level-3 products (the daily and monthly means) is outlined in the Cloud_cci ATBD [D1], Section 4. Note that within the scope of this project, the provided dataset constitutes only a subset of the original Cloud_cci cloud properties dataset. Furthermore, both monthly and daily level-3 files are so-called level-3C averaged composite products; the high-resolution level-3U files (where level-2 data is nearest-neighbour sampled) are not provided under C3S. The Cloud_cci PUG [D3] Annex C and the Cloud_cci Comprehensive Error Characterisation Report [D4] Section 6.1 describe the propagation of uncertainty into L3 products.
A set of additional products being produced specifically for the SLSTR ICDR are merged files, which replicate the existing level-3 data, but combine data from instruments on both Sentinel-3A and -3B. As the two Sentinel-3 platforms are in interleaved sun-synchronous orbits, combining data from both SLSTR instruments provides near global coverage twice-daily. The level-3 algorithm used to produce these merged files is identical to that used produce level-3 from each instrument separately.
3.4.1 Cloud fractional cover
Computation of cloud fractional cover consists of counting the number of pixels flagged as cloudy by the pre-processor cloud-mask, in each level-3 grid cell over the period covered by the level-3 product, and dividing that number by the total number of pixels (cloudy and clear) included. As the level-1b data has a ground-pixel of fixed size, this amounts to an area-weighted average of cloudiness for each level-3 grid cell. Details on the level-3 cloud fractional cover retrieval are given in Cloud_cci ATBD [D1] Section 4.2.1.
3.4.2 Cloud physical properties
Level-3 cloud properties are calculated by calculating the simple arithmetic mean value of level-2 retrieval output across each level-3 grid cell, over the period covered by the level-3 product. The level-2 data has quality checks applied:
- The numerical optimisation should have converged to a stable solution, with a minimum cost function value (see Equation (1)) that shows the forward modelled radiances agree with the measurements within expected uncertainties.
- The retrieved state parameters should be physically reasonable and consistent.
Running totals of the data from pixels which pass these criteria are calculated (along with other parameters needed for standard deviation and uncertainty propagation) for all pixels within each grid cell, and then converted to averaged values, along with uncertainties once all level-2 data has been read.
Details on the level-3 cloud physical properties retrieval are given in Cloud_cci ATBD [D1] Section 4.2.2.
4. Output data
This section summarises information on the output files.
4.1 File format
Cloud_cci TCDR and SLSTR ICDR products are provided to the CDS in NetCDF (version 4), which are compliant with the conventions CF 1.8 and the NASA Global Change Master Directory (GCMD) Science Keywords vocabulary. Filenames follow the structure:
C3S-312bL1-L3C-MONTHLY-CLD-INSTORACPLATFORM{}YYYYMM{_}_fv3.0.nc,
or
C3S-312bL1-L3C-DAILY-CLD-INSTORACPLATFORM{}YYYYMMDD{_}_fv3.0.nc,
where INST and PLATFORM refer to the instrument and platform from which data originates (either ATSR2 and ERS2, or AATSR and ENVISAT for TCDR data, or SLSTR and Sentinel-3a, -3b or -3a+b for ICDR data for each individual Sentinel-3 platform, or the combined product from both platforms). YYYYMM or YYYYMMDD provide the year, month and (in the case of daily products) day covered by the mean product, while V.V indicates the product version number (v3.0 for the TCDR, v3.1.1 for the individual Sentinel-3 ICDR and v4.0 for the combined Sentinel-3 product).
4.2 File contents
Table 4-1 and Table 4-2 are listing respectively the monthly and daily parameters included in the output files generated under the C3S for the Cloud Properties products. In the monthly datasets, excluding the parameters related to the geographic grid (longitude and latitude) and to the cloud pixel classes (cloud pixel count, liquid cloud pixel count, ice pixel count and cloud fractional cover), each parameter has four related variables, which are the mean value of the data itself (for example, the mean cloud-top pressure is found in the ctp variable), followed by the standard deviation of the data, denoted by _std, the propagated uncertainty, denoted by _unc, and the spatially correlated uncertainty, denoted by _cor. The definition and details of the calculation of these terms is given in the Cloud_cci Comprehensive Error Characterisation Report [D4]. Data are provided on a regular latitude-longitude grid. For monthly products this grid has a spacing of 0.5° in both dimensions (thus grid centres lie at -89.75°, -89.25°, -88.75°, …, 89.75° in latitude and -179.75°, -179.25°, -178.75°, …, 179.75° in longitude). Daily products have a grid spacing of 0.1° in both dimensions.
Both daily and monthly data files have common global attributes, which are defined in Table 4‑3. All data arrays (aside from the lat/lon arrays defining the geographic grid) in the monthly products are 720×360 element arrays, while those in the daily files are 3600×1800 elements. In both cases, these arrays coincide with global coverage at the spatial resolutions defined in the previous section. In the case of daily files, data are separated into daylight and night data, based on a solar zenith angle cut-off. This separation is done for two main reasons:
- In locations where the daylight (descending half of the orbit) and night sections (ascending half of the orbit) overlap, data values separated in time by approximately 12 hours would be combined if a simple daily average was taken. Not only can such an average not be considered a valid daily-mean, but will result in inconsistent results in adjacent sections of the orbit track which do and do-not overlap.
- Cloud optical depth and effective radius rely on information for the shortwave (A)ATSR or SLSTR channels, and thus are not retrieved for night pixels. Thus, in order to provide a consistent set of cloud properties for each retrieval, only daylight cloud top pressure, height and temperature as well as water path should be included in the averaging where effective radius and optical depth are present.
Table 4‑1: The data variables included in the Cloud_cci TCDR and SLSTR ICDR monthly cloud properties files brokered to, or produced for, the CDS.
Property | Unit | Variable name | Comment |
Latitude | Degrees North | lat | Values correspond to grid centres (-89.75°, -89.25°, -88.75°, …, 89.75°). |
Longitude | Degrees East | lon | Values correspond to grid centres (-179.75°, -179.25°, -178.75°, …, 179.75°). |
Cloud pixel count | - | pixel_count pixel_count_day | The number of level 2 cloud pixels included in the averaging. Totals are given for all pixels and daylight pixels. |
Liquid cloud pixel count | - | liquid_count liquid_count_day | The number of level2 pixels, classified as liquid water cloud, included in the averaging. Totals are given for all pixels and daylight pixels. |
Ice cloud pixel count | - | ice_count ice_count_day | The number of level2 pixels, classified as ice water cloud, included in the averaging. Totals are given for all pixels and daylight pixels. |
Cloud fractional cover | - | cfc cfc_unc | The cloud fractional-area cover, defined as the fraction of level 2 pixels within each level 3 grid cell flagged as cloudy. |
Cloud-top pressure | hPa | ctp ctp_std ctp_unc ctp_cor | The pressure at the cloud top, as determined from thermal infrared emission. This value is directly related to cth and ctt by ECMWF ERA profiles. |
Cloud-top height | km | cth cth_std cth_unc cth_cor | The height of the cloud top above mean sea level, determined from thermal infrared emission. This value is directly related to ctp and ctt by ECMWF ERA profiles. |
Cloud-top temperature | K | ctt ctt_std ctt_unc ctt_cor | The temperature at cloud top, determined from thermal infrared emission. This value is directly related to ctp and cth by ECMWF ERA profiles. |
Cloud effective radius | µm | cer cer_std cer_unc cer_cor | The effective radius of cloud droplets or ice crystals. |
Cloud optical thickness | - | cot cot_std cot_unc cot_cor | The column optical thickness at a wavelength of 500 nm. |
Liquid water path | gm-2 | lwp lwp_std lwp_unc lwp_cor | The column mass of liquid cloud water. |
Ice water path | gm-2 | iwp iwp_std iwp_unc iwp_cor | The column mass of ice cloud water. |
Table 4‑2: The data variables included in the Cloud_cci TCDR and SLSTR ICDR daily cloud properties files brokered to, or produced for, the CDS.
Property | Unit | Variable name | Comment |
Latitude | Degrees North | lat | Values correspond to grid centres (-89.95°, -89.85°, -89.75°, …, 89.95°). |
Longitude | Degrees East | lon | Values correspond to grid centres (-179.95°, -179.85°, -179.75°, …, 179.95°). |
Cloud pixel count | - | pixel_count_day pixel_count_night | The number of level 2 cloud pixels included in the averaging. Totals are given for daylight and night pixels separately. |
Liquid cloud pixel count | - | liquid_count_day liquid_count_night | The number of level2 pixels, classified as liquid water cloud, included in the averaging. Totals are given for daylight and night pixels separately. |
Ice cloud pixel count | - | ice_count_day ice_count_night | The number of level2 pixels, classified as ice water cloud, included in the averaging. Totals are given for daylight and night pixels separately. |
Cloud fractional cover | - | cfc_day cfc_night cfc_day_unc cfc_night_unc | The cloud fractional-area cover, defined as the fraction of level 2 pixels within each level 3 grid cell flagged as cloudy. |
Cloud-top pressure | hPa | ctp_day ctp_night ctp_day_std ctp_night_std ctp_day_unc ctp_night_unc ctp_day_cor ctp_night_cor | The pressure at the cloud top, as determined from thermal infrared emission. This value is directly related to cth and ctt by ECMWF ERA profiles. |
Cloud-top height | km | cth_day cth_night cth_day_unc cth_night_unc | The height of the cloud top above mean sea level, determined from thermal infrared emission. This value is directly related to ctp and ctt by ECMWF ERA profiles. |
Cloud-top temperature | K | ctt_day ctt_night ctt_day_unc ctt_night_unc | The temperature at cloud top, determined from thermal infrared emission. This value is directly related to ctp and cth by ECMWF ERA profiles. |
Cloud effective radius | µm | cer_day cer_day_std cer_day_unc cer_day_cor | The effective radius of cloud droplets or ice crystals. |
Cloud optical thickness | - | cot_day cot_day_unc | The column optical thickness at a wavelength of 500 nm. |
Liquid water path | gm-2 | lwp_day lwp_day_unc | The column mass of liquid cloud water. |
Ice water path | gm-2 | iwp_day iwp_day_unc | The column mass of ice cloud water. |
Table 4‑3: List of global attributes included in the Cloud_cci TCDR and SLSTR ICDR cloud properties files brokered to, or produced for, the CDS.
Attribute name | Description |
title | Descriptive title of the file contents |
Project | “Climate Change Initiative-European Space Agency” |
product_version | The version number of the product |
conventions | Lists the naming and meta data conventions used |
standard_name_vocabulary | Defines the standard name convention used |
Institution | The source institution of the data |
Source | The source (level 1) data used in the product |
geospatial_lon_resolution | The grid spacing in the longitude axis |
geospatial_lat_resolution | The grid spacing in the latitude axis |
geospatial_lon_min | The minimum longitude covered by the product |
geospatial_lon_max | The maximum longitude covered by the product |
geospatial_lat_min | The minimum latitude covered by the product |
geospatial_lat_max | The maximum latitude covered by the product |
spatial_resolution | Alternative description of the spatial grid used. |
geospatial_vertical_min | Definition of vertical grid used (0 indicated no vertical grid) |
geospatial_vertical_max | Definition of vertical grid used (0 indicated no vertical grid) |
Platform | Satellite platform from which observations originated |
Sensor | Satellite sensor which made the observations used |
creator_email | |
creator_url | |
date_created | ISO date and time string of processing time of the particular file |
creator_name | Alternative for institution |
time_coverage_duration | ISO time string defining temporal coverage of the product |
time_coverage_resolution | ISO time string defining temporal resolution of the product |
references | Link to further information about the product |
history | Brief description of provenance of the product |
summary | Brief description of product contents |
keywords | List of keywords (for data discovery) |
comment | Any further comments on the product not covered by other fields |
license | License conditions of the product |
cdm_data_type | Common Data Model Data Type used in the NetCDF file |
keywords_vocabulary | The standard list from which the keywords have been extracted |
naming_authority | ID string of the institution naming product (and contents) |
tracking_id | An ISO Universally Unique Identifier (UUID) number for the file |
id | A human readable identifier of the product |
time_coverage_start | ISO time string of the start of the product’s temporal coverage |
time_coverage_end | ISO time string of the end of the product’s temporal coverage |
inputfilelist | List of the primary input files used to create the product |
References
AATSR Detailed Processing Model Level 1b. Ref: PO-TN-RAL-GS-10004, https://earth.esa.int/eogateway/documents/20142/37627/AATSR-Detailed-Processing-Model-Level-1B.pdf (Last accessed on 23/01/2023)
ENVISAT-style products for ATSR-1 and ATSR-2 data. Ref: APP-TN-005, https://earth.esa.int/eogateway/documents/20142/37627/Envisat-style%20products%20for%20ATSR-1%20and%20ATSR-2%20data (Last accessed on 23/01/2023)
McGarragh et al. "The Community Cloud retrieval for CLimate (CC4CL). Part II: The optimal estimation approach", Atmospheric Measurement Techniques (2017). DOI: https://doi.org/10.5194/amt-2017-333
Rodgers, "Inverse Methods for Atmospheric Sounding", World Scientific (2000). DOI: https://doi.org/10.1142/3171
Sentinel-3 SLSTR Technical Guide. https://sentinels.copernicus.eu/web/sentinel/technical-guides/sentinel-3-slstr/instrument (Last accecssed on 23/01/2023)
Stamnes et al. "Numerically stable algorithm for discrete-ordinate-method radiative transfer in multiple scattering and emitting layered media", Appl. Opt., 27, 2502--2509, 1988, https://doi.org/10.1364/AO.27.002502
Sus et al. "The Community Cloud retrieval for CLimate (CC4CL)–Part 1: A framework applied to multiple satellite imaging sensors.", Atmospheric Measurement Techniques (2017). DOI: https://doi.org/10.5194/amt-2017-334
References are listed in ESA Cloud_cci ATBD [D1], Section 6; ESA Cloud_cci CC4CL ATBD [D2]; ESA Cloud_cci PUG [D3], Section 6; in ESA Cloud_cci CECR [D4], Section 11; in ESA Cloud_cci ATBD (MLEV) [D5], Section 4; in AATSR Level 1b Detailed Processing Model, Section 3; in ENVISAT-style Products for ATSR-1 and ATSR-2 data, Section 8; and Sus et al. 2017 and McGarragh et al. 2017.
This document has been produced in the context of the Copernicus Climate Change Service (C3S).
The activities leading to these results have been contracted by the European Centre for Medium-Range Weather Forecasts, operator of C3S on behalf on the European Union (Contribution Agreement signed on 22/07/2021). All information in this document is provided “as is” and no guarantee of warranty is given that the information is fit for any particular purpose.
The users thereof use the information at their sole risk and liability. For the avoidance of all doubt, the European Commission and the European Centre for Medium-Range Weather Forecasts have no liability in respect of this document, which is merely representing the author’s view.