Some OLCI results show strange invalid patterns

Post Reply
martin.boettcher.bc
Posts: 5
Joined: Thu Oct 10, 2019 3:04 pm
company / institution: Brockmann Consult GmbH
Location: Hamburg, Germany

Some OLCI results show strange invalid patterns

Post by martin.boettcher.bc »

Dear Francois,

some OLCI products (e.g. S3A_OL_1_EFR____20180509T083238_20180509T083538_20180510T131627_0179_031_064_1980_MAR_O_NT_002.SEN3) processed with v4.12 show something like in the right image, in comparison to e.g. the same product processed with v4.0 (left).
polymer-4.0-versus-4.12.png
Both are processed with NCEP auxiliary data. Do you know why this happens? What can I do to avoid it?

Best regards,
Martin

--
Dr. Martin Boettcher
Brockmann Consult GmbH
phone: +49(0)40 696389-315
email: martin.boettcher@brockmann-consult.de
skype-id: martin.boettcher.bc
--
Brockmann Consult GmbH
Chrysanderstr. 1
D-21029 Hamburg, Germany
Amtsgericht Hamburg HRB 157689
Geschäftsführer Dr. Carsten Brockmann
Web: www.brockmann-consult.de
Twitter: @BrockmannCon
--
You do not have the required permissions to view the files attached to this post.
User avatar
fsteinmetz
Site Admin
Posts: 306
Joined: Fri Sep 07, 2018 1:34 pm
company / institution: Hygeos
Location: Lille, France
Contact:

Re: Some OLCI results show strange invalid patterns

Post by fsteinmetz »

Hi Martin,

Thanks for your feedback.
This kind of patterns is typically due to un unstability of the algorithm. Polymer uses the result of previous pixel to initialize the minimization of current pixel, which can lead to successive (vertically) bad pixels within a processing block (which is a horizontal stripe of 100 pixels for OLCI) in case of unstability of the minimization scheme.
Between v4.0 and v4.12, most changes that could be related to this kind of patterns are the changes in vicarious calibration coefficients, and the fact that band 412 is not used for atmospheric correction since v4.11. I would expect this last change to avoid unstable situations, but apparently the opposite is happening here.
I will have a look at this case because some updates of Polymer are underway (not in the short term). In the meantime, you should be able to reproduce the behaviour of v4.0 by providing the following options to run_atm_corr: calib=None, bands_corr = [412,443,490,510,560,620,665, 754,779,865], bands_oc=[412,443,490,510,560,620,665, 754,779,865].

Cheers,
François
jcardoso
Posts: 12
Joined: Fri Feb 08, 2019 10:17 am
company / institution: National Institute for Space Research
Location: Brazil

Re: Some OLCI results show strange invalid patterns

Post by jcardoso »

Dear François,

I am trying to apply the command that you wrote in the post above to avoid the strange patterns (I also observed this issue).
I am receiving an error saying that cannot find "calib".

- Should I add some module in the polymer_cli.py to recognize the calib=None?
- The calib=None and the rest of the command that you suggested are to write inside Level1, correct?

Thank you for the help,
Be safe, Joao
User avatar
fsteinmetz
Site Admin
Posts: 306
Joined: Fri Sep 07, 2018 1:34 pm
company / institution: Hygeos
Location: Lille, France
Contact:

Re: Some OLCI results show strange invalid patterns

Post by fsteinmetz »

Hi Joao,

These arguments are to be passed to the function "run_atm_corr", which is the main function called in polymer_cli.py.
You can modify the last lines of polymer_cli.py like so:

Code: Select all

    run_atm_corr(Level1(args.input_file),
                 Level2(filename=args.output_file, fmt=args.fmt),
                 calib=None,
                 bands_corr=[412,443,490,510,560,620,665,754,779,865],
                 bands_oc=[412,443,490,510,560,620,665,754,779,865],
                 )
However, I do not guarantee that it will fix the unstabilities in your case.
Kind regards,
François
Post Reply