Earthdata Forum

Hi,

We have downloaded some time ago VIIRS SNPP L1A data, without last few years. Now I can see that file name format changed: instead of V2019164192400.L1A_SNPP, we see something like SNPP_VIIRS.20190613T192400.L1A.nc. The file content however, if we compare the same granules, did not change, at least in the files I have checked. Metadata also stays the same, in particular, creation time.

Does this mean that instead of re-downloading existing L1A data, it is sufficient just to re-name them?

Thank you.
Cheers,
Andrei

Yes, when we adopted the new 2020 naming convention, we renamed the existing L1A.
They are the same files.

Tommy

Hi,

When renaming to the latest convention SNPP VIIRS L1A files in our local storage, downloaded few years ago, still in format V2012049033600.L1A_SNPP.nc, I have noticed some of our local files could not be found at the NASA storage: https://oceandata.sci.gsfc.nasa.gov/directdataaccess . We always (I think) had 240 files daily, and now often I cannot find corresponding files at the NASA site, not every day, often 1-2 a day, but for some extreme cases as many as 30, like, e.g., for 2012-02-18; here are examples of such now missing files for that day: V2012049000000.L1A_SNPP.nc, V2012049000600.L1A_SNPP.nc, V2012049001200.L1A_SNPP.nc, V2012049001800.L1A_SNPP.nc, V2012049030600.L1A_SNPP.nc, V2012049034800.L1A_SNPP.nc, etc. - totally 30 are missing.

The question: why the files have been removed? Any good reasons? Can we use them (remaining locally)?

Thank you.

Why yes, there is a good reason:

https://oceandata.sci.gsfc.nasa.gov/odps_dashboard/events?page=1&start_date=2012-02-18&end_date=2012-02-19&sensor=14

Can't explain why you ever had data in the affected time period, as there was no data to be had.

Regards,
Sean

Hi Sean,

Thank you for the reply and explanations. I am still not quite happy with the answer. That case in the very beginning of the satellite life , Feb 18, 2012, was indeed an extreme case: I checked - we neither could produce L2 files from those L1A files though we do have those L1A files.

How about other approx 600 granules, only by the end of 2019? We did not download later data then. There are probably no such large gaps like 30 files missing, but 1-2 granules daily missing in NASA archives but present in ours - a common situation. For example, 2015/03/30, two Day time granules, both looking quite reasonable, L1A and resulting (POLYMER processed) L2 files, for V2015089164200 and V2015089165400, the day gap bounds in the EARTHDATA are: 16:36 to 17:00.

The questions stay the same: was there a reason(s) to delete those granules from NASA archives and can we use those files or better not?

Thank you.
Cheers,
Andrei

PS I can send the files or images of the results if you do not have them

Andrei,

Looking at the 30 March 2015 date, the "missing" granules were QC failed (determined to be of bad quality) because of a spacecraft maneuver to execute a lunar calibration. This affected 2 full 6 minute granules and partially affected 2 others, though we do set the QC failure status on a granule level so, despite the fact that there may be recoverable data in the two granules partially impacted by the maneuver, the entire granule is failed. This or other similar situations are the cause for over 13,000 granules over the life of the SNPP mission to be QC failed. While that may seem like a lot, there are a LOT of granules (over 1.1 million).

We recently updated our distribution code to ignore the QC failed files, which probably explains why you have data we're not longer distributing. If you are able to successfully process the files declared QC failed (for many, I'm sure you cannot), you can choose to use the data. We chose to not do so.

Regards,
Sean