Last modified on Sept 04, 2023 16:39

Contributors: B. Calmettes (CLS), JF. Crétaux (CLS), C. J. Merchant (University of Reading), L. Carrea (University of Reading) and R. Maidment (University of Reading)

Issued by: B. Calmettes
Date: 21/04/2021
Ref: C3S_312b_Lot4.D1.LK.4-v3.0_LWL_Algorithm_Theoretical_Basis_Document_i1.0.docx
Official reference number service contract: 2018/C3S_312b_Lot4_EODC/SC2

History of modifications

List of datasets covered by this document

Related documents

Acronyms

Scope of the document

This document is the Algorithm Theoretical Basis Document (ATBD) for product C3S ECV LK – LWL (Lake Water Level), version CDR 3.1. It describes the theoretical basis and justification that underpins the implementation of the Lake Water Level in the context of the C3S. It details the methodology to be applied on the satellite altimetry data. Moreover, it provides an evaluation of the algorithm performance and a description of the limitations.

Executive summary

The C3S Lake production system (C3S ECV LK) provides an operational service, generating lake surface water temperature and lake water level climate datasets for a wide variety of users within the climate change community. The present document covers the lake water level system. The LWL science team and the LWL system development team developed water level retrieval algorithms in order to meet user requirements. The algorithms are designed to derive the most possible benefit from the active and passive input data streams and achieve the best quality. Regular quality monitoring exercises are conducted to ensure that the algorithms allow the LWL product to move towards user requirements targets.

1. User Requirements

There not having been a precursor ESA Climate Change Initiative project addressing the Lake ECVs, we are not aware of any substantive survey of user requirements for satellite-derived lake products. Presently, this section relies on statements for the Lake ECV from GCOS [D 1], published literature, experience from other CDR projects, and requirements emerging from the definition of the service. The requirements will be updated in future versions using requirements that emerge from users of the service and their feedback, and from any user requirements survey that is undertaken in a future CCI project.  The user requirements are indicated in Table 1.

Table 1: User Requirements for Water Level as described in GCOS

2. Methodology Description

2.1. Overview

The monitoring of water levels of large lakes and reservoirs from space is performed by the measurements of radar altimeters onboard several past, existing and on-going space missions.

The CNES/LEGOS laboratory performed most of the pioneer work in that domain and conceived the HydroWeb website and products in the early 2000's. The objective was to provide worldwide users with space-derived water level time series. Several hundreds of continental lakes are presently delivered offline by HydroWeb.

In 2015, CNES, which has supported for many years the R&D efforts aiming at improving the level 2 products, decided to develop the HYSOPE (HYdrométrie Spatiale OPErationnelle) processor as a fully operational version of HydroWeb. The objective of this CNES initiative was to deliver operational hydrology products for fostering the development of scientific and user applications and entrusted CLS with maintenance and exploitation of the system.

The HYSOPE/HydroWeb processor is used as the processing chain for the production of lakes water level variable in the framework of the Copernicus Climate Change Service.

The requirements for the development of HYSOPE are:

• To be based on input products which production and access are warranted
• To be able to include future altimeters with consistent product quality
• To be able to integrate a much larger number of targets
• To deliver water level products within a maximum time delay of 3 days after acquisition
• To provide products of peer-recognised scientific quality: publication of procedures, algorithms and validation results.

2.2. The retrieval Algorithm

2.2.1. Outline

The processing for lakes is a 3-step process as illustrated in Figure 2. All interesting high frequency measurements inside the lake shape for all missions are used (example on Figure 1).

Figure 1: Example of Lake Superior with ground track coverages of Jason-3 (red) and Envisat (white)
The processing of a median water level for each lake takes into account:

• The altitude
• The lake profile

Figure 2: Overview of the processing for lakes

The resulting products are in NetCDF format and 140 lakes worldwide are processed on an operational basis. The time series is updated within 3 days after measurement, with a temporal coverage depending on the altimetry mission coverage (10 days for Jason-3, 28 days for Sentinel-3A and Sentinel-3B). The accuracy depends on the altimetry missions used and on the shape of the lake. The average overall and mission-specific accuracy is included in the PQAR.

Figure 3 illustrates the content of the data file for Lake Amadjuak (Canada). The blue dots represent the Lake Water Level corresponding to each satellite observation, while the red bars quantify the water surface height mean absolute deviation of the individual measurements used to derive the water level. The blue line simply connects the dots. Note that the time series has been computed since late 1992, starting with TOPEX/Poseidon until 2002, with Jason-1 between 2002 and 2008, with Jason-2 between 2008 and 2016, and with Jason-3 since October 2016.

Figure 3: Plot of the water level time series corresponding to Hysope processing for Lake Amadjuak

2.2.2. Basic underlying assumptions

The space missions used to calculate changes in lake and reservoir levels are repetitive, i.e. the satellite passes over the same point on Earth after a constant time interval (of the order of 10 days, 28 days or 35 days depending on the type of orbit, respectively Jason-3, Sentinel-3/SRAL and SARAL/AltiKa for example). Each mission guarantees the ground position at nadir in a "cross track" band of +/- 1km.

For a given lake, depending on its size, one or more satellites - and for each satellite, one or more tracks - can overfly it.

When the satellite is above the lake, the measurements are acquired along the track on the water surfaces, processed on board (waveform acquisition) and then reprocessed on the ground with several different waveform analysis models, respectively named ocean, ice1, ice2 and Seaice. Through these 4 algorithms, 4 measurements of satellite distance / reflective surface are available. Depending on the size of the lake, one type of waveform reprocessing model is chosen. This choice is made by the experts from the Science Team and the information is accessible for each lake and each satellite via the master file used for launching the computation. The names of the variables of the "range" type make it possible to distinguish the type of model from "retracking" used.

The temporal sampling of the measurements along the track is 1s (measurement at 1Hz) for all the satellites, and measurements at 1/20s for Jason-2 and Jason-3 (18Hz measurements) and 1/40s for the SARAL/AltiKa mission are available within the products. For most of the lakes to be monitored, the ocean algorithm (waveform corresponding to a Brownian model) will be used with measurements at 1 Hz, with a few exceptions (lakes of reduced size for which the ice1 model and 1/20s or 1/40s measurements are used). In all cases, this choice is defined for the entire length on the time series and instructed in the master file.

The processing consists in calculating for each passage of one of the satellites above a given lake the mean level along the track and in incrementing the time series with this new level value of the lake at the date of the passage. The list of lakes and tracks is known and included in the processing master file.

2.2.3. Input data

For lakes and reservoirs, the altimetry data processed for the operational production are those of Jason-3, Sentinel-3A and Sentinel-3B.
The STC update of the products is done using I-GDR-like (Interim Geophysical Data Records) data, while in case of complete reprocessing, GDR-like data are used instead. The data provided by the AVISO distribution centre (https://www.aviso.altimetry.fr/en/data/data-access/aviso-cnes-data-center.html) are delivered daily for I-GDRs and once the cycle is complete for GDRs. The delivery time of these products is of the order of 2 days for the I-GDR. For potential reprocessing, only the GDRs will be used and there is, by definition, no delivery time consideration for these reprocessing.
The input data needed for the processing (/ reprocessing) are:

• Altimetric measurements and associated corrections (I-GDR and GDR) issued by AVISO (Jason-3) or Copernicus Hub (Sentinel-3A and Sentinel-3B) .

• A master file listing all the lakes of the database with processing information for each of these lakes (tracks number, geographical limits on the lake for each track segment, keys to take into account and type of correction for the humid troposphere, bias to be applied, type of tracker to be used). The lake selection presented in the current version of the product has been established by experts. Criteria were the selection of the largest lakes over which previous hydrological information was available for initialisation.

• A file that lists some parts of the lake to be excluded from the processing.

• A file with the average profiles along the tracks of each satellite above each lake of the data base. These average profiles have been calculated with the history of the past missions and can be used because the missions in progress are placed in orbits common to past missions (Jason-3, Jason-2, Jason-1 and T/P share the same reference orbit, similarly to Envisat and Saral / Altika). The mean profile corresponds to the variation in height of the geoid above the ellipsoid. As a first approximation, this height at each point along the track can be obtained using a geoid model, but even the best of them cannot capture the small wavelengths of the undulations of the geoid that are permanently present on a lake surface. These short wavelengths of the geoid had therefore to be calculated with the past missions (assuming that the vertical profile is constant along the track whatever the mean level variation of a lake) and are subtracted for each new passage of the satellite above a lake under a given track. For Sentinel-3A, this work of generating the average vertical profiles along the tracks on the lakes of the database has been done before the implementation in the processing chain.

• A file listing standard level derivatives from historical observations. In order to eliminate a cycle that would clearly be out of the ordinary level range, and for each lake, the mean change in the level per unit of time was calculated. For each new cycle measured, a test is carried out to compare the new level with the last validated level, to ensure the level remains within limits of "acceptable" variations. This information is stored in a dedicated file that is "queried" by the algorithm at the end of the processing.

The altimetry measurements at the input of the processing are archived at CNES (for Jason-3, AVISO), Copernicus Hub (Sentinel-3A, SciHub or CopHub) and CLS. All the master files and data files needed to process the altimetry measurements are provided by the Science Team.
In the event of GDRs data update for past or current missions as a result of the definition of new standards for GDRs, the entire lakes database may be reprocessed. For past missions it will be performed by the Science Team, while for the missions in progress, this will be done by the HydroWeb/HYSOPE processor for Short-Time Critical processing.

2.2.4. Output product

The Product User Guide and Specification (PUGS) [D 6] contains the complete description of the output product in NetCDF format. The files generated during the processing are the following (for external and internal use):

• the updated water level time series including the uncertainty and the metadata
• the corresponding graphs
• the control data of the processing for possible further analyses (in case of detected problems)
• an updated archive of the cycles eliminated.

3. Methodology

3.1. General Description

The processing takes place according to an identical sequence of tasks. The articulation is quite simple. It consists of four main stages:

• Extract / select / read measurements from each of the IGDR files (Short-Time Critical mode) and calculate the water levels along the track.
• For the case of a possible reprocessing, from the GDR files, all the measurements on all the lakes will be extracted.
• Recovery of the average profiles for the selected tracks and calculation of the lake level for the current track. Validation of the last tracks processed.
• Creation of graphs, "Product Files" and update on the database.

Each of these steps uses "subroutines" with a number of input files, whether they are master files supplied by the Science Team, or the outputs of the previous "subroutines".
The processing consists of three sequential main steps (Figure 2). A final step (Step 4) consists in updating the water level database:

• Step 1:
  • Reading IGDR / GDR data. This data comes from different missions and may have different variable names.
  • Reading master files (name of lakes, number of tracks and name of satellites, bias to be applied, retracking model used, track segments on the lake: a track can intersect a lake several times, depending on the presence of islands or emerged land areas. The reading master file is in text format. This file is defined for internal use only and it is not provided to the final user.
  • Extraction of measurements on each lake overflown by the satellite during the period considered according to the instructions in the master file. This file is in text format.
  • Elimination of data according to predefined editing (corrections, flags). This information, in text format, allows the later evaluation of the system quality.

For a given lake in the processing phase, the output of this step is a text file with the set of pre-selected and filtered measurements which will be used in the next step, and a file of control of the measurements rejected from the flags and the editing criteria.

• Step 2
  • Calculation of the water level above the reference ellipsoid at each preselected measurement point.
  • Reading of the file of the average profiles and recovery of the profiles of the lakes flown over.
  • Subtraction of the mean profile on the levels at each point of measurements which have just been calculated.
  • Rejection of outliers along the track (by Standard Deviation test).
  • Calculation of the median level for the considered cycle and of the associated SD.

For a given lake in the processing phase, the output of this step is a file in text format with the dates, levels and standard deviations that have just been calculated, as well as two control files, one including the rejected measurements and the other measures selected during this step.

• Step 3
  • Reading the file of the level derivatives of each lake provided by the Science Team (allows to give a "reasonable" a priori of the variations of level of a given lake by time step). The information about the maximum accepted variations is only available internally.
  • Tests on the rejection of "outlier cycles" for each of the lakes processed during the period.
  • Writing (update) the lake water levels in the "Product File"
  • Production of graphs

For a given lake in the processing phase, the output of this step is a new text file with the calculated water levels and the associated uncertainties. The final NetCDF file is generated with this information.

3.2. Step 1: GDR Product selecting and editing

3.2.1. Theoretical description: Overview

Whatever the mission and whatever the lake, this step is unique. The altimetry database is explored for the latest measurements since the last update. The chain reads the master file in which are indicated all the studied lakes, and the different characteristics of the processing specific to each of these lakes.

When measurements corresponding to a passage from the satellite are found on one of the lakes included in the master file, the data to be processed on this lake can be extracted along the current track and the process continues until the last measurement so that to pre-select all the measurements that are located on the studied lakes.

A set of "editing" parameters is queried to decide whether to select or reject each of the measurements along the current track. These editing parameters are identical for each satellite and each lake except for the editing on the dry tropospheric correction. This parameter is included in the lakes master file. Indeed, the correction of the dry troposphere is a direct function of the atmospheric pressure and therefore of the altitude of the lake surface. The editing here consists of defining realistic limits of this correction, which is therefore different for a lake of low altitude and for a lake of high altitude.

All parameters are extracted from the altimetry database. For current missions (Jason-3, Sentinel-3A, Sentinel-3B) the IGDR and GDR files provide both high-rate (20 Hz) instantaneous measurements as well as the average measurement over one second for orbit and range estimates and geographic coordinates. However, the corrections - atmospheric or tidal - are provided in low resolution (1Hz).

For large lakes, the chain preferably uses 1Hz measurements with the Ocean retracking, while for small lakes the OCOG Retracking is selected with high rates (the geophysical corrections are duplicated to match the measurements). This choice is indicated in the program via the master file reading at the beginning of processing in this step.

The chain does not use the quality flag based on the use of altimetric measurements over the oceans, however it uses the flags on the individual corrections provided in the IGDRs and the GDRs, if any (for example a flag is used for the ionospheric correction and for the wet troposphere corrections).

3.2.2. Process flow

The sequence is the same for the whole altimetry missions. However, only the case of current missions: Jason-3, Sentinel-3A and Sentinel-3B are described here. For other missions, only the input measurements files, and therefore the nomenclature of the parameters, change.
This step proceeds as follows:

1. Opening of the master file (text format) of the lakes including the part of the track to be used for the lake water level and also the segments to be excluded from this track due to intersection with emerging lands (for example, the track crossing an island in the lake).
2. Pre-selection of acquired tracks that cut each of the studied lakes (there are potentially several lakes monitored per day).
3. Selection of measurements that are exactly on the track (taking into account the different keys of the master file and of the sections to be excluded: longitude bounds for each track, mode key for taking into account the wet troposphere correction, bias to be applied, and section to be removed).
4. Application of criteria for the rejection of individual measurements on the lake: first according to the existing flag (a Jason-3 measurements can be flagged, this does not exist for Sentinel-3A) and then by a list of criteria on the extracted parameters, also known as "Editing".
5. Writing the output file that corresponds to the measurements selected after this step and the control file that list the rejected measurements on the lake.

3.2.3. Interfaces

3.2.3.1. Input data

Altimetric data file
Input parameter to be extracted: example from Jason-3 IGDR or GDR downloaded from AVISO. The fields are very similar for Sentinel-3A.

Table 2: Example of Jason-3 IGDR or GDR data file downloaded from AVISO.

Note: for corrections of wet troposphere and ionosphere, it is necessary to extract both the model value (model_wet_tropo_corr and iono_corr_gim_ku) and the instrumental corrections (rad_wet_tropo_corr and iono_corr_alt_ku). The correction from model is used as a backup in the case where the instrumental correction is flagged.

For the wet troposphere, the choice of the default value and thus of the backup value is given in the master file. For the ionospheric correction, the instrumental correction is chosen by default and the value of the model is only used in case of flag of the instrumental value.

Master Files

Two files are used in this stage of processing: master file and exclusion file. The first one gives the processing conditions for all the lakes, while the second one is dedicated solely to lakes where one or more tracks may cut the same lake several times. In these cases, it is necessary to remove segments along the track to avoid calculating levels on land in the direct environment of the lake. These files are not provided.

Figure 4 and Figure 5 present examples of a master file and an exclusion file for a lake. The master file contains the information about all the monitored lakes.

Figure 4: Lake master file: example over the lake Argentino.

This file contains for each lake a descriptive heading followed by information to be used by track crossing the lakes. The header includes:

• Number of tracks over the lake,
• The name of the lake
• Abbreviation of the continent
• Retracking data to be used: 'normal' for data from ocean model algorithm or 'OCOG' for data from Ice1 algorithm

Then as many lines as the number of tracks with:

• Track number,
• Minimum and maximum limits along the track in longitude,
• Constant bias (inter trace / inter mission) to be applied to each measurement along the trace
• A key to take into account the particular ground track (0: no taken into account, 1: taken into account)
• A key for the default wet troposphere correction (0: not taken into account, 1: depending on model, 2: according to radiometer),
• The name of the satellite,
• Minimum and maximum bounds in the case of an interleaved orbit.

An "interleaved" orbit corresponds to an orbit at the end of life when a new mission of the series has been launched. The orbit is offset in longitude as the case was for the transitions from TOPEX/Poseidon to Jason-1, then for Jason-1 to Jason-2, and recently for Jason-2 to Jason-3.

The exclusion file contains a series of lines, each one with the name of a lake, a number defining the used satellite, the number of segments to be rejected, and then for each segment, the number of the track and the limits (min and max) in longitude to be rejected.

Figure 5: Lake exclusion file: Example over the lake Argentino

In the above example, over the lake Argentino, mission ERS-2/RA (mission code = 4), 3 segments must be removed: two segments from track 347 and one segment from track 10. Regarding the Envisat/RA-2 mission (mission code = 5), two segments are rejected, both on track 695.

3.2.3.2. Output data

For each new processing, the chain enriches both a file with the rejected measurements and a file of the selected measurements resulting from the previous processing steps containing high frequency corrected altimetry data. Both files are in text format. The selected measurements file is used in the following step, while the rejected measurements file is used for diagnosis purposes.

3.2.4. Mathematical description

3.2.4.1. Function 1: Geographical selection of measurements on lakes for a given day

Objectives: Reading of data on all the lakes of the database and the parameters that will allow the selection of measurements and geographical selection of the measurements on each of the lakes.
Input: IGDR measurement file of each satellite; parameter files.
Output: Table of measurements in text format (with corrections) actually located above each lake overflown during the day.

3.2.4.2. Function 2: Flag selection and "editing" of preselected measurements

Objectives: For all the measurements that have been geographically preselected, it is necessary to check whether the values of the measurements and corrections are flagged or not and then add the tests of "editing". The flagged values and the "editing" considered are described in Annex A.
Input: Measurement table from Function 1.
Output: Separated text files with selected and rejected measurements.

3.2.5. Quality control and diagnostics

If no measurements are selected at the end of Step 1 for a lake overflown by a satellite during the processing day, an error alert code is raised and archived.

3.3. Step 2: Processing and filtering

3.3.1. Theoretical description: Overview

The mean profile along each track is computed in advance by the Science Team and is provided as a file regrouping the set of profiles of each track for each lake of the database. This information is only available internally.

Once the measurements have been selected in the previous step, the next step will be to compute for each measurement the lake level at this point by applying the corrections, as well as an additional correction, not extracted from the IGDR measurements, but from an a priori correction file provided by the Science Team. This correction concerns the vertical bias that must be applied to each measurement to correct the height of the geoid above the reference ellipsoid. Indeed, the geoid over a lake has permanent vertical oscillations that are too tiny to be detected in the existing geoid grids, even the most accurate ones. For the calculation of the median level of a lake for a passage of a satellite, this corresponds to a vertical profile along the track to be removed. These profile values have all been calculated beforehand and are provided via a profile file in text format.

A second part of this step consists of removing the outliers along the track after calculating the median level of the lake along the track (this elimination is iterative and based on the standard deviations of each measurement relative to the calculated median level at each iteration).
For each measurement we can define the height of the lake at this point above the geoid by the formulas below:

WSH = altitude – corrected_range (equation 1)

With: Corrected_range = range_ku + dry_tropo + wet_tropo + iono + tides (pole and solid)

WSH is the level above the ellipsoid.

To have the Water Level (WL) at the level of the geoid it is necessary to calculate:

WL = WSH – geoid (equation 2)

The value of the geoid considered here is extracted from the file of average profiles (cf. above).
Once all the water heights have been calculated along the track, it remains to calculate the median and then the corresponding standard deviation.
At the end of this calculation, additional editing must be carried out:

• In a first iteration each height measurement is compared with the median measurement that has just been calculated, and if the absolute value of the deviation from the median measurement is greater than 1.5 times the value of the standard deviation, it is discarded.
• A new median value with the associated standard deviation is calculated at the end of the first iteration in order to proceed with a second (then third and fourth) iteration on the same principle with the selected values but a removal criterion equivalent to 2 times the standard deviation.

Therefore, four iterations are carried out unless no measurement is rejected in one of them.

3.3.2. Interfaces

3.3.2.1. Input data

The input data is:

• The profile files (one file per lake, satellite and track) for the geoid correction in equation 2.
• The output file from Step 1 with the selected measurements

3.3.2.2. Output data

The output data, in text format, is the file containing the median level and associated error of the valid measurements.
A file containing the rejected altimetry data is also generated with the purpose of being used in the future for diagnostic purposes.

3.3.3. Mathematical description

3.3.3.1. Function 1: Geoid correction

Reading the file containing the selected measurements from Step 1, and the profile file for the lake/satellite/track processed. This function allows to calculate the water height at each point along the track considered, on the lake considered, from equation 1.
In a second stage, interpolation in the profile file of the closest reference point with respect to the measurement point being processed (calculation of the distance between the measurement point to be corrected and the corresponding reference points in the mean profile file) and then apply the geoid correction according to equation 2.

3.3.3.2. Function 2: Editing

Once the set of measurements has been corrected for the various parameters, including the mean profile, as indicated in function 1, additional editing is carried out as described in section 3.2.1.
At the end of this editing, a file tracking the measurements that were filtered is saved, as well as a file tracking the selected measurements. These two files serve as controls of the processing. Finally, a third file is created for each lake with the set of cycles that have been processed. It should be noted that during this stage, since all the data of the previous day is processed, several satellites may have flown over a given lake, and in this case, there may be several successive lake level calculations, and thus several lines in this file.

3.3.4. Quality control and diagnoses

If no measurements have been selected at the end of Step 2 for a lake overflown by a satellite during the processing day, an error alert code shall be assigned and archived. The warning codes for each step (1, 2 and following) must make it possible to differentiate the type of rejection of the measurements on a given lake, in order to help the operator for a later evaluation of the problem.

3.4. Step 3: Time series update

3.4.1. Theoretical description: Overview

The last step is to retrieve the last validated file for each lake that has just been processed, and to increment it with the new levels resulting from the calculation that has just been done. In this third stage, the last median level measurements of the lake are validated. For this, a file which indicates the maximum accepted variations of level for a lake by time step is queried. This internal file is created and provided by the hydrological experts from Science Team. It is based on the history of the lake or reservoir level variations in the database, which allowed to estimate a level variation threshold limit value. The level variation between the most recent estimate and the last validated estimate is compared to this reference level variation value. Should it exceed this value, the new estimate is not validated. It is, therefore, a third level of editing after those set up in the first two steps of the processing.

The thresholds for time-variations of water level are defined for each lake. These values were set by experts who accounted for the history of water level changes within the lake or reservoir. Over reservoirs, regulation effects are therefore also accounted for, unless there is an unprecedented large regulation intervention that exceeds all the prior ones recorded within the prior value.

These threshold values are included in a file (one value per lake) that is read at the input of this step of the algorithm.

For each new passage of a satellite on a lake, one calculates:

Where the index "last" represents the last validated cycle (which can be n but also a date even earlier according to previous eliminations), L the measured level of the lake and t the date. The last validated measurement must be read, provided it is "remote" at least 5,5 days (empirical value) from the measurement to be tested. If the last date is too close, the previous date will be searched until we get a sufficiently distant date.

A weighting factor of 1.4 is applied to the maximum value Dmax of the drift. In other words, any measurement of height of the lake for which DMlast is greater than 1.4Dmax will be rejected. In the opposite case, the lake water height for the passage under consideration is definitively validated.

Once this calculation has been completed, it only remains to update the product file with the last tracks processed for each of the lakes of the day.

3.4.2. Interfaces

3.4.2.1. Input data

The input data is:

• File of last validated cycles (see 3.3.2.2).
• The last product file for the lake under consideration (to be done for each studied lake).

The file of the typical variations of each lake (used to edit the cycles). These standard variations are read at each new processing in order to check whether the level of the lake that has just been calculated remains within validated margins.

3.4.2.2. Output data

Final water level time series file in C3S netCDF format.

3.4.3. Mathematical description

3.4.3.1. Function 1: Validation

Validation of the last passage(s) processed for each lake at the end of Step 2. The algorithm described in equation 3 is applied (test on average and maximum drifts of the level of the lake).

3.4.3.2. Function 2: Writing output data

If necessary, writing of the water level in the new product file.

3.4.4. Quality control and diagnoses

If the height of the lake at the end of Step 3 could not be validated for a lake overflown by a satellite during the processing day, an error alert code is raised and archived.

The alert codes for each stage (1, 2 and 3) make it possible to differentiate the type of rejection of the measurements on a given lake, in order to help the operator for a later evaluation of the problem.

A rejection flag (for each lake processed each day) can be assigned and automatically transmitted to the operator.

4. Limitations

The lake processing chain, initially developed at LEGOS, is based on the use of altimetry measurements from the CTOH database (Center for Topography of the Oceans of LEGOS), including Envisat GDRs. This database includes, in addition, some enhanced corrections that are not in the data sets of institutional suppliers (Aviso, ESA), such as for the wet and dry tropospheric as well as for the ionospheric corrections. As part of the online version of HYSOPE (that serves Copernicus Climate Change Service), these tailored corrections are replaced by default by their corresponding standard corrections included in the operational input products. On the other hand, a module for calculating the height of the geoid has been developed in the operational chain, starting from a grid provided by the LEGOS.

5. Quality Assessment

When reading the individual satellite measurements over a lake, a number of tests are performed, and error or validation flags are allocated. The test performed and their corresponding flag value are indicated in Annex A. Each measurement, thus, has a flag which is zero if the measurement is validated.

The "editing" therefore corresponds to tests on threshold values for the corrections applied to the measurement. Note that in the input data themselves (e.g. from Aviso) parameters can already be flagged: the standard value being that of the fill_value associated with each of the variables.

Annex A Description of the flags

Related articles

• Page:
  ECV - Glaciers, Ice Sheets, Lakes, Soil Moisture
• Page:
  IV Version 1.2; SEC Version 2.0; GMB Version 2.0: Product User Guide Specification (PUGS)
• Page:
  IV Version 1.2; SEC Version 2.0; GMB Version 2.0: System Quality Assurance Document (SQAD)
• Page:
  IV Version 1.2; SEC Version 2.0; GMB Version 2.0: Product Quality Assurance Document (PQAD)
• Page:
  IV Version 1.2; SEC Version 2.0; GMB Version 2.0: Product Quality Assessment Report (PQAR)