Cloud_Coverage_Assessment value when using sen2cor

[sylar11]

Hi all,
I’m using the latest version of sen2cor 2.10.01 to create the L2A product.
I can run the process using a docker I created.
When I compare the Cloud_Coverage_Assessment value I get with sen2cor with the one of the corresponding L2A file from SciHub it results that they have different values.

For example, I’m using as an input file the following file: S2A_MSIL1C_20220411T101601_N0400_R065_T32TPT_20220411T124038.zip
when I run my docker using sen2cor using the following command

docker run --name=test_docker -t --rm -v /mnt/RAM_DISK/data/:/home/desuser/data/ -v /raid0/DES/scripts/L2A/test_processing_scripts/test_processing_container/L2A_GIPP.xml:/home/desuser/sen2cor/2.10/cfg/L2A_GIPP.xml -e INPUT_IMAGE=S2A_MSIL1C_20220411T101601_N0400_R065_T32TPT_20220411T124038.SAFE sen2cor2.10.01_file /home/desuser/processing_scripts/run_sen2cor.sh

It creates the MTD_MSIL2A.xml file where I find this value:
<Cloud_Coverage_Assessment>99.999999</Cloud_Coverage_Assessment>

For the corresponding file on SciHuB: S2A_MSIL2A_20220411T101601_N0400_R065_T32TPT_20220411T135651.SAFE/MTD_MSIL2A.xml
it results: <Cloud_Coverage_Assessment>1.267885</Cloud_Coverage_Assessment>

Could you please tell me what I’m doing wrong?

[clausmichele]

@ABraun could you help us here? At EURAC Research we are experiencing this stange issue with the latest version of sen2cor, which prevent us from using the cloud coverage assessment value later on in our pipeline.

[ABraun]

sorry, haven’t used sen2cor since a longer time. Maybe @Jan knows if some of the metadata have changed?

[Jan]

Hello @clausmichele @ABraun
I’m not aware of any issue in the latest release of Sen2Cor, but I’ll check with a processing of the L1C on my side.

Jan

OPT-MPC S2 Technical Manager

[sylar11]

@Jan thanks for doing this check. I really will look forward to knowing your results.
I did various tests with a series of L1C files (one is in my initial question) and I always got the same error.

[Jan]

Hello @sylar11 Bart

I have processed S2A_MSIL1C_20220411T101601_N0400_R065_T32TPT_20220411T124038.SAFE in Sen2Cor 02.10 in TOOLBOX mode on my Windows 7 64 Bit laptop, both with the ESACCI-LC Package (as identified in the S2-PDGS-MPC-L2A-SUM-V2.10.0 and installed in my Lib\site-packages\sen2cor\aux_data folder) and without. I used the L2A_Process.bat on the command line.

In both instances, the value of <Cloud_Coverage_Assessment> in the MTD_MSIL2A.xml is 0.099870.

(I realise this value is different from the SciHub L2A value, but this may be explained because I didn’t use the ESACCI_SnowCondition Map).

Thus, I don’t replicate the 99.999999 seen by in your processing.

Jan

OPT-MPC S2 Technical Manager

[sylar11]

@Jan could you please write the command you used? I’m using an UBUNTU VM and I nedd to call sen2cor using the command line

[Jan]

Hi Bart @sylar11
it was a straight “point and shoot” after I’d unzipped the product:

Jan

[sylar11]

Hi @Jan I run sen2cor without the docker using the following command:

 /home/desuser/sen2cor_v2_10/bin/L2A_Process /mnt/RAM_DISK/data/S2B_MSIL1C_20220416T101559_N0400_R065_T32TNR_20220416T160249.SAFE

and when looking for the cloud value I get

less /mnt/RAM_DISK/data/S2B_MSIL2A_20220416T101559_N9999_R065_T32TNR_20220520T123733.SAFE/MTD_MSIL2A.xml | grep Cloud
    <Cloud_Coverage_Assessment>3.679504</Cloud_Coverage_Assessment>

and it seems correct now I will perform some other test. Perhaps there is an error in my docker. I will check it better.

In the meanwhile I have another doubt: is it correct that in the created MSIL2A filename it appears N9999 and not the initial orbit number N0400?

[Jan]

Hi @sylar11

Yes…

Sen2Cor-02.08.00-Linux64 generates output with different naming convention (*_N9999_*)

Hello, Reading th SUM, It appears that you have to set the processing baseline on the command line, and that 99.99 is the default. And the ESL_L2A confirm that it is not a bug, but a way to identify products generated in stand-alone mode and not by the PDGS. They note that with the previous version (2.5.5) it was only replicating the L1C baseline number. Cheers Jan

Cheers

Jan

[sylar11]

@Jan thanks for the clarification about the naming convention of L2A with sen2cor.

The sen2cor is now reproducing the correct value for the cloud coverage assessment but, unfortunately, in some cases I’m facing now another error:

/home/desuser/sen2cor_v2_10/bin/L2A_Process /mnt/RAM_DISK/data/S2B_MSIL1C_20220430T100019_N0400_R122_T33UWP_20220430T120209.SAFE

Traceback (most recent call last):

File “/home/desuser/sen2cor/lib/python2.7/site-packages/sen2cor/L2A_Process.py”, line 734, in sys.exit(main())

File “/home/desuser/sen2cor/lib/python2.7/site-packages/sen2cor/L2A_Process.py”, line 568, in main
if not config.setProductVersion():
File “/home/desuser/sen2cor/lib/python2.7/site-packages/sen2cor/L2A_Config.py”, line 5598, in setProductVersion
if (productVersion == int(12)):
UnboundLocalError: local variable ‘productVersion’ referenced before assignment

I tested also this file: S2B_MSIL1C_20220429T102549_N0400_R108_T32TMP_20220429T124017.SAFE and I got the same output.

Could you please check if you have the same error with these files?

[Jan]

Hi @sylar11
No. I didn’t get that at all. I processed 32TMP with Sen2Cor 02.10.01 and everything went OK: processing completed successfully - taking around 18 minutes for the Tile.

Cheers

Jan

[sylar11]

@Jan thanks again for your precious support and patience. I found the error. Now it is working for me too.