Project

General

Profile

Support #26231

[PyCAMA] Verify configuration of PyCAMA for daily extractions

Added by Maarten Sneep over 1 year ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Phase E2 - PyCAMA 1.0
Start date:
06/16/2020
Due date:
12/11/2020
% Done:

0%


Description

Before reprocessing with version 2 starts, the configuration of PyCAMA must be "fixed", in both senses: correct and frozen. Long term monitoring relies on stability of both the L2 processing, and the monitoring tool.

I need feedback from all algorithm leads on the configuration of PyCAMA for their product. Either confirm that the configuration is good, or indicate what needs to change.


Related issues

Related to PyCAMA - Support #26241: [PyCAMA] Supply list of up to 12 parameters you want to follow over time In Progress 06/16/2020 12/11/2020
Related to PyCAMA - Support #28421: Prepare for version 2 quality control monitoring. New 10/15/2020 12/11/2020

History

#1 Updated by Maarten Sneep over 1 year ago

  • Related to Support #26241: [PyCAMA] Supply list of up to 12 parameters you want to follow over time added

#2 Updated by Maarten Sneep over 1 year ago

  • Start date changed from 06/08/2020 to 06/16/2020

#3 Updated by Maarten Sneep over 1 year ago

  • Assignee set to Jacques Claas

#4 Updated by Athina Argyrouli over 1 year ago

For the CLOUD PyCAMA configuration for daily extraction, the current format is in general in good shape from our perspective.
Two points could be improved if there is any potential for updating/changing the configuration. Those are the following:
  • Is the latitude grid in the zonal average plots fixed? For the cloud parameters, it looks too dense for a daily average plot, whereas usually when we create such type of zonal mean plots we use a latitude grid of 5 degrees. Is it possible to adjust this?
  • Adjusting the boundaries for global maps and histograms of the parameters RMS and RMS_CRB from the current range [0 – 0.1] to [0 – 0.01] is suggested.

#5 Updated by Maarten Sneep over 1 year ago

Athina Argyrouli wrote:

For the CLOUD PyCAMA configuration for daily extraction, the current format is in general in good shape from our perspective.
Two points could be improved if there is any potential for updating/changing the configuration. Those are the following:
  • Is the latitude grid in the zonal average plots fixed? For the cloud parameters, it looks too dense for a daily average plot, whereas usually when we create such type of zonal mean plots we use a latitude grid of 5 degrees. Is it possible to adjust this?

The latitude bands for the zonal average can be adjusted independently from the world-plot (in the original version of the zonal average the two were linked). This is not an issue, this can be set for individual products.

  • Adjusting the boundaries for global maps and histograms of the parameters RMS and RMS_CRB from the current range [0 – 0.1] to [0 – 0.01] is suggested.

Will do.

#6 Updated by Athina Argyrouli over 1 year ago

Thank you Maarten!
Since the latitude bands for the zonal average plots could be adjusted independently, could you please select a grid with a resolution of 5 degrees? At the moment, it seems much finer and the zonal plots have noisy spikes.

#7 Updated by Maarten Sneep over 1 year ago

Athina Argyrouli wrote:

Thank you Maarten!
Since the latitude bands for the zonal average plots could be adjusted independently, could you please select a grid with a resolution of 5 degrees? At the moment, it seems much finer and the zonal plots have noisy spikes.

Yes. This will be part of the next (post-DDS2B) delivery.

#8 Updated by Maarten Sneep about 1 year ago

  • Related to Support #28421: Prepare for version 2 quality control monitoring. added

#9 Updated by Maarten Sneep about 1 year ago

  • Due date changed from 09/04/2020 to 12/11/2020

#10 Updated by Klaus-Peter Heue about 1 year ago

For the ozone daily reports, a few plotting details might be updated.
For NRTI "Figure3: Fraction of pixels with specific warnings and errors during processing" is not readable, I suggest dividing it into two plots and and skip the lines between the markers.
NRTI Figure 10&35 "DOAS fit wavelength shift" change the scales to "-0.02 to 0.02"
figure 11&36 "DOAS fit wavelength squeeze" change scales to "-0.003 to 0.003"
NRTI please include "INPUT_DATA/surface_albedo"

OFFL please include "DETAILED_RESULTS/effective_albedo" in the plots

#11 Updated by isabelle de smedt about 1 year ago

For HCHO the daily reports look fine.
Some scales could be better adapted:

Figure 10: Map of “Airmass factor total precision”: [0 , 2]
Figure 15: Map of “DOAS fit RMS (first interval)”: [0 , 0.004]
Figure 16: Map of “HCHO slant column correction”: [-3e-04 , 3e04] [mol/m²]
Figure 33: Histogram of “HCHO vertical column”Histogram of “HCHO vertical column: [-5e-04 , 5e-04]
Figure 45: Histogram of “HCHO slant column correction”: [-5e-04 , 5e-04]

Thank you.
Isabelle

#12 Updated by Ronny Lutz about 1 year ago

For L2_CLOUD, we would like to ask to add the following parameters for the daily extraction such that they can be used also for the time dependent monitoring:
/INPUT_DATA/surface_albedo_nir (only available since UPAS 2.1.3)
/INPUT_DATA/continuum_reflectance_oxygen_Aband

The OCRA cloud fraction was missing in the beginning, but it seems that /DETAILED_RESULTS/cloud_fraction_apriori has already been added to the daily extraction such that it can be included for the time dependent monitoring

Concerning the daily pdf reports:
NRTI: Figure 15 (OCRA cloud fraction):
- please reverse the colorbar from white(0)-blue(1) to blue(0)-white(1) to be consistent with Figures 4 and 7.
- the cloud_fraction_apriori is always provided, even when ROCINN is not triggered. While Figures 4-14 have gaps at pixels where ROCINN was not triggered, the OCRA Figures 15-17 should be gapless. Is this an issue of the data selection/extraction process?

OFFL: Figure 17 (OCRA cloud fraction):
- please reverse the colorbar from white(0)-blue(1) to blue(0)-white(1) to be consistent with Figures 6 and 9.
- the cloud_fraction_apriori is always provided, even when ROCINN is not triggered. While Figures 6-16 have gaps at pixels where ROCINN was not triggered, the OCRA Figures 17-19 should be gapless. Is this an issue of the data selection/extraction process?

Thanks,
Ronny

Also available in: Atom PDF