MODISA start time at 1 ms, modis_GEO.py filename causes scripts to fail

[schckngs]

Hi oceancolour forum, quick question,
I am processing MODISA L1A data using modis_GEO.py. The output GEO files recently started having the automatically generated filename ending in '1', causing my scripts to later fail, as the L1A file start time is at 1 ms rather than 0.
For example,
modis_GEO.py A2006252184000.L1A_LAC
Will generate a file named A2006252184001.GEO
The start time for this file (among many others from 2016) is A2006252184001 (output from modis_GEO.py -v below)
Is this a problem with the L1A file, ancillary data, etc?
Thanks,
Andrea


modis_GEO.py A2006252184000.L1A_LAC -v
** Files utcpole.dat/leapsec.dat are more than 2 weeks old.
** Running update_luts.py to update files...

Downloading files into /home/hilborna/ocssw/var/modis
...no new files.

Downloading files into /home/hilborna/ocssw/var/modisa
...no new files.

Downloading files into /home/hilborna/ocssw/var/modisa/cal/OPER
...no new files.

Downloading files into /home/hilborna/ocssw/var/modisa/xcal/OPER
...no new files.
Determining required attitude and ephemeris files...
Searching database: /home/hilborna/ocssw/var/ancillary_data.db

Input file: A2006252184000.L1A_LAC
Sensor    : modisa
Start time: 2006252184001
End time  : 2006252184500

  Found: /home/hilborna/ocssw/var/anc/2006/252/PM1ATTNR.P2006252.1800.003
  Found: /home/hilborna/ocssw/var/anc/2006/252/PM1EPHND.P2006252.1200.001

Creating MODIS geolocation file...
MODIS GEO version 6.1.0, built Aug 16 2019 12:46:24
scan: 0 out of 203 Wed Nov 27 13:40:39 2019
scan: 10 out of 203 Wed Nov 27 13:40:40 2019
scan: 20 out of 203 Wed Nov 27 13:40:40 2019
scan: 30 out of 203 Wed Nov 27 13:40:41 2019
scan: 40 out of 203 Wed Nov 27 13:40:41 2019
scan: 50 out of 203 Wed Nov 27 13:40:41 2019
scan: 60 out of 203 Wed Nov 27 13:40:42 2019
scan: 70 out of 203 Wed Nov 27 13:40:42 2019
scan: 80 out of 203 Wed Nov 27 13:40:42 2019
scan: 90 out of 203 Wed Nov 27 13:40:43 2019
scan: 100 out of 203 Wed Nov 27 13:40:43 2019
scan: 110 out of 203 Wed Nov 27 13:40:44 2019
scan: 120 out of 203 Wed Nov 27 13:40:44 2019
scan: 130 out of 203 Wed Nov 27 13:40:44 2019
scan: 140 out of 203 Wed Nov 27 13:40:45 2019
scan: 150 out of 203 Wed Nov 27 13:40:45 2019
scan: 160 out of 203 Wed Nov 27 13:40:46 2019
scan: 170 out of 203 Wed Nov 27 13:40:46 2019
scan: 180 out of 203 Wed Nov 27 13:40:46 2019
scan: 190 out of 203 Wed Nov 27 13:40:47 2019
scan: 200 out of 203 Wed Nov 27 13:40:47 2019
geogen_modis returned with exit status: 0
Percentage of pixels with missing geolocation: 0.00
Validation test passed for geolocation file A2006252184001.GEO
geogen_modis created A2006252184001.GEO successfully!
MODIS geolocation processing complete.


[gnwiii]

There are a number of ways to deal with the possible variations in the generated filename.  One is to specify the name you want for the GEO file using the modis_GEO.py argument list (--output <filename>).  Another is to use a filename pattern such as A200625218400?.GEO that will match both A2006252184000.GEO or A2006252184001.GEO when used in a bash command line or script.

[schckngs]

Thanks gnwiii, that is an easy workaround for sure.
I am wondering why this happens though? I just processed MODISA 2003-2019 for a region of interest in the arctic and this difference only occurs for a few months during 2006.
-Andrea

[OB.DAAC - SeanBailey]

The reason is simple...script derives the filename from the start time of the first scan line of the granule.  That time does not always fall exactly on the 5 minute boundary. 
Sean