modis_GEO cannot detect platform short name

[gbourdin]

Hello,
I am getting an error running modis_GEO on MODIS-Aqua and MODIS-Terra level-1A scenes:

/etc/magic, 0: Warning: using regular magic file `/usr/share/misc/magic'
file: could not find any magic files!
Running debug binaries...
/home/gbourdin/ocssw/bin
Traceback (most recent call last):
File "/home/gbourdin/ocssw/bin/modis_GEO", line 113, in <module>
sys.exit(main())
File "/home/gbourdin/ocssw/bin/modis_GEO", line 100, in main
modis_env(m)
File "/home/gbourdin/ocssw/bin/modis/modis_utils.py", line 271, in modis_env
self.start, self.stop, self.sat_name = modis_timestamp(self.filename)
File "/home/gbourdin/ocssw/bin/modis/modis_utils.py", line 158, in modis_timestamp
sat_name = meta['ASSOCIATEDPLATFORMSHORTNAME'].lower()
TypeError: 'NoneType' object is not subscriptable

I found this post reporting the same error: https://oceancolor.gsfc.nasa.gov/forum/ ... l?tid=6322
I have tried unzipping the *.bz2 files a second time with bzip2, but it didn't change anything.

Thank you,
Guillaume

[OB SeaDAS - xuanyang02]

I am assuming you are using SeaDAS 8.1.0. What tag of OCSSW are you using? You can run the following command and post the result here.

Code: Select all

/home/gbourdin/ocssw/bin/seadas_info

Please also share the name of your L1A file(s).

[gbourdin]

Here it is for OCSSW:

NASA Science Processing (OCSSW):
Environment {$OCSSWROOT}: /home/gbourdin/ocssw
Environment {$OCDATAROOT}: /home/gbourdin/ocssw/share
l2gen version: msl12 9.5.1-V2021.2 (Jun 18 2021 11:22:53)
l2bin version: 7.0.1
l3bin version: 5.13
l3mapgen version: l3mapgen 2.3.0-V2021.2 (Jun 18 2021 11:24:42)
Installed Missions: ['aqua', 'terra', 'viirsn', 'viirsj1']

I get an error when it tries to recover the system info, but I work on my university server which is running on CentOS Linux 7.

I have a couple of thousands of images scattered a little bit everywhere in the Atlantic and Pacific Oceans.
One of them: A2016212184500.L1A_LAC.bz2

Thank you,
Guillaume

[OB SeaDAS - xuanyang02]

Where did you get your L1A files?

Can you do the following command and see if ASSOCIATEDPLATFORMSHORTNAME is in the metadata of your L1A file?

Code: Select all

ncdump -h A2016212184500.L1A_LAC |grep "ASSOCIATEDPLATFORMSHORTNAME"

[gbourdin]

ASSOCIATEDPLATFORMSHORTNAME seems to be in the metadata:

Code: Select all

OBJECT                 = ASSOCIATEDPLATFORMSHORTNAME\n        CLASS                = \"1\"\n        NUM_VAL              = 1\n        VALUE                = \"Aqua\"\n      END_OBJECT             = ASSOCIATEDPLATFORMSHORTNAME\n\n

News since this morning, after restarting my processing code several times this morning it started to work again. But I did not change anything, I just re-ran the code...
I would like to find out what happened to prevent it to happen again. This analysis is part of an automated process I designed to send myself custom products while I am at sea, so it must be robust.

A little bit of history might help to understand the issue:
The same problem occurred on the same dataset I processed last week. It was not working at first with any of the same ~2000 images and then started processing them normally after several trials. I wasn't sure it started working again after I investigated some functions in OCSSW to find the issue. Unfortunately, I had to delete and reprocess all the images because I didn't select the right products. Then I tried to start over, and this is when the same problem occurred again and I wrote my first post. This time I am sure I didn't change anything and it is now running.

My python software downloads the images using the package requests and the corresponding URL:

Code: Select all

https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/A2016212184500.L1A_LAC.bz2

Then it calls the bzip2 function to unzip every file before processing them:

Code: Select all

check_call([os.path.join(os.path.dirname(sys.executable), 'bzip2'), '-dk', 'A2016212184500.L1A_LAC.bz2'])

I used it over the past year to process > 10000 images without any problem. The settings shouldn't have changed but we never know what happens with SeaDAS.

I understand the difficulty to troubleshoot remotely an issue that is happening randomly, but I would greatly appreciate any advice on this one.
Thank you,
Guillaume

[OB SeaDAS - xuanyang02]

I am not sure if you are aware that our oceandata site was going through maintenance and not stable in the past week. Maybe that was causing the problems.

[gbourdin]

I was aware.
It might be possible the maintenance could cause the problem to happen in the first place, although it would mean the products were modified or the downloads were affected, but I don't see how the maintenance would make my process suddenly work again if I didn't re-download any images.