Forum

Brock,

It looks like the download issue you're seeing is affecting everything not just the ancillary data.

On a whim I checked our other subscriptions (which are all for L2 data). It looks like we stopped downloading any new data between 15:00 and 17:00 UTC yesterday (8/8).

-Andrew L.

When I try to download data with the getfile api it fails with an error of the form$ wget --no-use-server-timestamps --read-timeout=10 -O /tmp/A2019219181000.L1A_LAC.bz2 https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/A2019219181000.L1A_LAC.bz2--2019-08-09 02:58:51--  https://oceandata.sci.gsfc...

I'm getting the following error on two different computers when running l2gen on a MODISA granule...Loading DEM info from /marine-services/ocssw/share/common/ETOPO1_ocssw.nc-E- /home/seadas/ocssw/src/l2gen/sstref.c : Unable to initialize SST file/marine-services/ocssw/var/anc/2019/212/N2019212_S...

If I have an L2 SST granule with the day_night_flag set to "Mixed", is there a method to determine which pixels within the granule are day vs night vs dusk?

Is the answer any different for VIIRS NPP vs VIIRS N20 vs MODISA?

-Andrew L.

Sean,Thank you, as always, for your helpful hints. I tried with the straylight flag and while it removed almost all of the cloud contamination (yaay!) it also dropped more pixels than we would like :(.You said the flag is based on reflectance at 869nm - is that rrs_869, rhos_869, the cloud_albedo pr...

Hi again SeaDAS'ers :)Is there a way (or ways) to adjust the cloud flag determination in l2gen to be "more aggressive" in flagging cloudy pixels? I'm finding that we're getting contaminated data (for the purpose of our algorithm) at / near the edge of cloudy areas.In case it ma...

Sean,

Thank you for the explanation. It sounds like that granule has a bit of an "identity crisis"...

I ended up changing my scripts to ignore abnormally small L1A files.

-Andrew L.

Thank you Sean, that would make sense...

For some reason that night time granule turned up in a subscription that was supposed to be day only (id #2130) you might want to double check the selection logic.

Good morning.For some reason the commandmodis_L1B.py A2019120081000.L1A_LAC A2019120081000.GEOis not currently generating the expected A2019120081000.L1B_HKM file. It's a silent failure with no errors / warnings / etc. Any ideas as to what is going wrong?PS I also tried modis_L1B.py --hkm=A20191...

That helped a lot, thank you!

I think (but can't be sure) that the other errors are the file system getting full.