Forum

I'm seeing missing data on our source. I'll compare our counts with theirs and see if any can be recovered on our side. I doubt MODIS will be doing any recovery on their side. I'll update when I know more.

Tommy

I can trace the problem better if you tell me how you are accessing the data and provide an example of a missing granule.

Thanks
Tommy

l2gen only needs the first file:
ifile=Oa01_radiance.nc
geofile=geo_coordinates.nc

It processes all from there.

Tommy

The Raman Correction was computed already, that output is l2gen processing the file. These are chunky L1B files that take a while to process.

Tommy

Try adding share to the OCDATAROOT

os.environ['OCDATAROOT'] = '/.../l2gen/ocssw/share'

and there should be an olci directory under share

Tommy

The forum software may have filtered the code attachment to prevent distribution of malicious code.
Do not run the code if you cannot verify its actions.

Tommy

The L2 file names are derived from the start time of the data in the L1B granule, which is later than the start time in L1B file name Can you add logic in your script to search forward by incrementing the L1B time by 1 sec in the expected L2 file name and check until it finds a match or reaches a li...

There are times when the definitive ATTEPH files that get published are bad, and can't be processed.

When this happens we fall back to using the predicted ephemeris.

Which input files are you using?

Tommy

You can find the source L1B files here:
https://oceandata.sci.gsfc.nasa.gov/directdataaccess/Level-1B/S3A-OLCI/
https://oceandata.sci.gsfc.nasa.gov/directdataaccess/Level-1B/S3B-OLCI/

Tommy

Thanks for reporting the problem. There likely won't be a fix in place until Monday 10/7

Tommy