SeaDAS versioning affecting Landsat chl processing

Use this Forum to find information on, or ask a question about, NASA Earth Science data.
Post Reply
lukecarberry
Posts: 19
Joined: Fri Apr 09, 2021 4:50 pm America/New_York

SeaDAS versioning affecting Landsat chl processing

by lukecarberry » Fri Jul 01, 2022 2:34 pm America/New_York

Hi all,

I am trying to process a Landsat 8 L1 image for chlorophyll in l2gen from the command line, but I am getting different errors based on the version of SeaDAS I have installed.

With SeaDAS R2022.5 installed, I get:
"Loading aerosol models from
-E- /home/dshea/ocssw/src/l2gen/aerosol.c: Error opening file _r30f95v01.hdf."

With SeaDAS T2022.14 installed (was installed to separately process a L9 L1B file), I get:
"Loading aerosol models from /scratch/coast/seadas/ocssw/share/oli/l8/aerosol/aerosol_olil8
Number of Wavelengths 8
Number of Solar Zenith Angles 33
Number of View Zenith Angles 35
Number of Relative Azimuth Angles 19
Number of Scattering Angles 75
Number of Diffuse Transmittance Wavelengths 8
Number of Diffuse Transmittance Zenith Angles 33
Number of aerosol LUT wavelengths (8) is not equal to number of sensor wavelengths (7)."

With SeaDAS R2022.3 installed, it works, and says:
"Loading aerosol models from /scratch/coast/seadas/ocssw/share/oli/aerosol/aerosol_oli
Number of Wavelengths 7
Number of Solar Zenith Angles 33
Number of View Zenith Angles 35
Number of Relative Azimuth Angles 19
Number of Scattering Angles 75
Number of Diffuse Transmittance Wavelengths 7
Number of Diffuse Transmittance Zenith Angles 33
Wavelengths - Sensor Aerosol model Diffuse transmittance
443.00 443.00 443.00
482.00 482.00 482.00
561.00 561.00 561.00
655.00 655.00 655.00
865.00 865.00 865.00
1609.00 1609.00 1609.00
2201.00 2201.00 2201.00

Limiting aerosol models based on RH.

Using Gordon & Wang aerosol model selection
and NIR correction with up to 10 iterations
Using bands at 865.0 and 1609.0 nm for model selection
Extrapolating from 1609.0 nm
80 aerosol models: 8 humidities x 10 size fractions"

What is going on here?

Ideally, I would have the latest version installed in order to process both L8 and L9 imagery, but I would also like to know what is happening with the aerosol correction. I have also been getting significantly different chl_oci chlorophyll concentrations based on whether I am using Landsat Collection 1 or 2 L1B files, which I am troubleshooting with Nima. Any advice on what is causing this issue and what I should do to get good chlorophyll output would be greatly appreciated. Thank you!!

Luke Carberry

Tags:

OB SeaDAS - xuanyang02
Subject Matter Expert
Subject Matter Expert
Posts: 380
Joined: Tue Feb 09, 2021 5:42 pm America/New_York
Answers: 1

Re: SeaDAS versioning affecting Landsat chl processing

by OB SeaDAS - xuanyang02 » Fri Jul 01, 2022 5:37 pm America/New_York

Regarding T2022.14, aerosol_olil8_default.hdf has nwave=8, which is probably causing the error "Number of aerosol LUT wavelengths (8) is not equal to number of sensor wavelengths (7)." You probably have to wait for the fix, unless T2022.15 works.

Regarding R2022.5, it seems the aerosol and rayleight directories are missing from ocssw/share/oli, which is probably causing the error "Error opening file _r30f95v01.hdf."

I assume R2022.3 works for both collection 1 and 2 of landsat 8 L1 B files. We'll look into the issue as to why you get different chl-oci from collection 1 and 2.

lukecarberry
Posts: 19
Joined: Fri Apr 09, 2021 4:50 pm America/New_York

Re: SeaDAS versioning affecting Landsat chl processing

by lukecarberry » Thu Jul 07, 2022 12:21 pm America/New_York

Thank you for the help. I think what is really happening is that I am getting significantly different chl_oci based on the OCSSW version I have installed. Speaking to Nima, it seems like this is a product of the vicarious calibration either not being applied or being applied when it shouldn't be. Do you have any advice about what version of OCSSW I should be using to produce chl_oci from L1B collection 2 Landsat 8 and 9 images? Is there any documentation anywhere that explains what differs between each of the R and T versions of OCSSW? E.g. R2022.5 vs. R2022.3 and T2022.14 vs T2022.15? Thanks!

OB SeaDAS - xuanyang02
Subject Matter Expert
Subject Matter Expert
Posts: 380
Joined: Tue Feb 09, 2021 5:42 pm America/New_York
Answers: 1

Re: SeaDAS versioning affecting Landsat chl processing

by OB SeaDAS - xuanyang02 » Mon Jul 11, 2022 3:35 pm America/New_York

We are sorry to say that no tags of OCSSW currently works with l2gen on Landsat 9 L1 B files. R2022.5 and T2022.14 might have the new code to process Landsat 9, but it cannot read the oli tables.

I assume R2022.3 works for both collection 1 and 2 of Landsat 8. However, we are using the same atmosphere correction parameters for both collection 1 and 2. You might want to consult Nima on how to use different parameters in msl12_defaults.par for collection 2 to get accurate results.

lukecarberry
Posts: 19
Joined: Fri Apr 09, 2021 4:50 pm America/New_York

Re: SeaDAS versioning affecting Landsat chl processing

by lukecarberry » Mon Jul 11, 2022 6:15 pm America/New_York

Thanks for the help. Is there any documentation anywhere that explains what differs between each the versions of OCSSW? I would like to look closely into what changes between each version. I would also like to keep track of when OCSSW works for L9 L1B. Thanks!

lukecarberry
Posts: 19
Joined: Fri Apr 09, 2021 4:50 pm America/New_York

Re: SeaDAS versioning affecting Landsat chl processing

by lukecarberry » Tue Jul 12, 2022 7:51 pm America/New_York

I just ran a Landsat 8 Collection 2 L1B image in l2gen T2022.17 on the command line and got unrealistically low chlorophyll values, again. This is the image label: LC08_L1TP_042036_20191012_20200825_02_T1 (though I don't think it's because of the image). Does anyone have any advice for what could be causing this?

In V2020.2, I was getting accurate chl values, and now they're way too low. I would use V2020.2 but it can't process Collection 2 images. In any of the recent l2gen versions, both Collection 1 and Collection 2 images turn up way too low. Is it possible that the vicarious calibration gains are not being applied? What controls that in SeaDAS? Thank you for the help.

lukecarberry
Posts: 19
Joined: Fri Apr 09, 2021 4:50 pm America/New_York

Re: SeaDAS versioning affecting Landsat chl processing

by lukecarberry » Wed Jul 20, 2022 12:35 pm America/New_York

Just reposting this because of the office hours. Wondering what controls whether the vicarious calibration gains are being applied in SeaDAS, and whether that has changed with the incorporation of Landsat 8 Collection 2 processing. Something seems to have changed within SeaDAS, because chlorophyll is coming out much too low. It was working in V2020.2, and has stopped in the recent updates. I would like to use the Collection 2 images, because they're a better product. Thank you!

OB.DAAC - SeanBailey
User Services
User Services
Posts: 1322
Joined: Wed Sep 18, 2019 6:15 pm America/New_York
Answers: 1
Been thanked: 1 time

Re: SeaDAS versioning affecting Landsat chl processing

by OB.DAAC - SeanBailey » Fri Jul 22, 2022 2:19 pm America/New_York

Luke,

Vicarious gains are always applied, although sometimes they are just a bunch of 1s ;)
The values are in the $OCDATAROOT/<sensor>[/platform]/msl12_defaults.par file

The issue you noticed was not a misapplication of the gains (well, not directly), but rather a change in the default gaseous absorption corrections (controlled by the gas_opt parameter). We are in the middle of our multi-mission reprocessing and one of the things that's changing is this gaseous absorption business. The default was changed to 45 (from 15) somewhat unintentionally. With the reprocessing we're now setting gas_opt in the sensor-level defaults files...but hadn't done so for OLI, so it picked up the global default. The gains were computed with the gas_opt=15, so when that became gas_opt=45 things went wonky for you.

The simple solution is to set gas_opt=15 in your processing (you could put it in the default file or on the command line or in your processing parameter file). We'll fix the global default to be 15 again, though you'll have to wait for the next tag.

Regards,
Sean

Post Reply