I have programs that splice consecutive granules together for processing eg:

cat MOD00.P2011139.1905_1.PDS MOD00.P2011139.1910_1.PDS > MOD00.P2011139.1905_2.PDS

When I run $SEADAS/run/scripts/modis_GEO.csh $l1afile -geocheck_threshold 95
on the resultant L1A file, half my geolocation fails with 49% of pixels with missing geolocation.
I suspect that the modis_atteph.py only reports the 1st NRT file thus 5 minutes.
If I create L1A files individually from MOD00.P2011139.1905_1.PDS and MOD00.P2011139.1910_1.PDS separately,
the geolocation works fine with 0% of pixels with missing geolocation for each of those files. It is only when I cat them together that I have the error.

Note that there are 2 granules that are found and l0cnst_write_modis figures it out. modis_atteph.py seems not to care so much.

Satellite: aqua
starttime: 2011-05-19T19:05:00.728539Z
stoptime:  2011-05-19T19:14:49.465023Z
duration:  588.736484 seconds

I have attached the log file as requested.

Brock,

The "Attach" button appears below each post after it's submitted.

The geolocation code was developed to run on 5-minute MODIS granules using 2-hour attitude files.  At most two attitude files would be needed, and then only to cover granules at the beginning or end of the att file.  At present, the geolocation only allows TWO att files to be input.  This is not under our control.

As you know, the NRT (predicted) attitude files now cover only 5 minutes.  This also is not in our control.

Because of that time constraint, near-real-time geolocation will always fail if the input granule is over 10 minutes.

Even so, your granule should have worked since it was only 10 minutes long.  Please try it again, but keep the log files:

$SEADAS/run/scripts/modis_GEO.csh $l1afile -geocheck_threshold 95 -save-log >&! geo.log

Then attach geo.log, $geofile.pcf, and any Log* file that looks like it has useful info.

Gwyn,

I have uploaded all files to the post above yours. Oddly, the geo.log file I cannot click on and view.
I have repeated the test many times with the same results. I re-uploded the geo.log as geo.out and that one I can see.
Must me a thing on your server restricting log file extensions.

Brock

Probably the geo.log file contains some text forbidden by our web server.  Looks like all the output was captured by 6.2.2a.txt anyway.

The key is in the LogStatus file:
PGS_EPH_getEphemRecords():PGSEPH_E_NO_SC_EPHEM_FILE:44547
input time outside range of staged ephemeris file(s)

The staged ephem files are listed in the pcf:
10501|PM1EPHND_NRT.A2011139.1905.005|/optics1/software/seadas/seadas_6.1/var/modis/atteph/2011/139||PM1EPHND_NRT.A2011139.1905.005|PM1EPHND_NRT.A2011139.1905.005|2
10501|PM1EPHND_NRT.A2011139.1900.005|/optics1/software/seadas/seadas_6.1/var/modis/atteph/2011/139||PM1EPHND_NRT.A2011139.1900.005|PM1EPHND_NRT.A2011139.1900.005|1

Of course it's the 1905 and 1910 eph files that should have been staged.  Can I take a look at your concatenated L0 file?

Gwyn

Never mind on that L0 file; I'm having the same trouble.

I'm guessing no luck yet.
Seems to work once the diffinative files are available. (Just not NRT)
Have you identified what is causing the wrong files to be identified?
Thanks again,
Brock

Still investigating!

One other thing while investigating. Why does the validation test on geolocation file pass and exit = 0 when it doesn't meet the 95 percent threshold?

modis_geocheck.py A2011143202000.GEO 95 --verbose
Percentage of pixels with missing geolocation: 49.000000
Validation test passed for geolocation file A2011143202000.GEO
MODIS geolocation processing complete.

exit_status=            0

Thanks,
Brock

OK,
Trying on newer files:
cat MOD00.P2011143.2020_1.PDS MOD00.P2011143.2025_1.PDS > MOD00.P2011143.2020_2.PDS

still fails though so will assume that the other problem still exists:

can: 390 out of 399 Tue May 24 13:05:28 2011
geogen_modis exit status: 0

Running validation test on geolocation file...
modis_geocheck.py A2011143202000.GEO 95 --verbose
Percent valid data (0.000000) is less than threshold 95.000000

modis_GEO.csh: ERROR: MODIS geolocation processing failed.

I wanted to attach the "LogStatus.A2011143202000.GEO" but it is too big as it has a ton in it:

-rw-rw-r-- 1 oo_processing oo_processing 109M May 24 13:05 LogStatus.A2011143202000.GEO

The resultant A2011143202000.L1A_LAC file displays fine in seadas.

Brock,

We've narrowed the problem down to the database query result.  The database returns all att/eph files that cover the input times, PLUS a few seconds before the start time.  Then the first two of each is selected as input to geogen_modis.

For a 5-minute granule, geogen_modis will read and discard the first file and then get the information it needs from the second file.

For a 10-minute granule, 3 att/eph files are selected but only the first two are passed to geogen_modis.  The first file is discarded and the second file covers scans in the first 5 minutes of the granule, but there is no 3rd file to cover the rest.

Sean will have to look at why the DB query is returning the earlier files.  If you must process 10-minute granules in the meantime, try setting STARTNUDGE to a non-zero value before you create the L1A file.

Gwyn

Gwyn,

cat MOD00.P2011145.0520_1.PDS MOD00.P2011145.0525_1.PDS > MOD00.P2011145.0520_2.PDS

Oddly, when I use startnudge 0

unix cmd =
$SEADAS/run/scripts/modis_L1A.csh /tmp/test3/MOD00.P2011145.0520_2.PDS -startnudge 0 -stopnudge 10; l1afile=ls -1t [AT]*.L1A_LAC | head -1; $SEADAS/run/scripts/modis_GEO.csh $l1afile -geocheck_threshold 95

It fails like this:

Scan Number: 390  Wed May 25 11:26:58 2011
l1agen_modis exit status: 0
MODIS L1A processing complete.
Determining required attitude and ephemeris files...
modis_atteph.py ./A2011145052000.L1A_LAC
We failed to reach a server.
URL attempted: http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/PM1ATTNR_NRT.A2011145.0515.005
Reason:  timed out*** ERROR: The HTTP transfer failed with status code 110.
*** Please check your network connection and for the existence of the remote file:
*** http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/PM1ATTNR_NRT.A2011145.0515.005
***
Traceback (most recent call last):
  File "/optics1/software/seadas/seadas_6.2.2a/run/scripts/modis_atteph.py", line 57, in ?
    m.locate()
  File "/optics1/software/seadas/seadas_6.2.2a/run/scripts/modules/modis_atteph_utils.py", line 197, in locate
    os.remove(self.server_file)
OSError: [Errno 2] No such file or directory: 'A2011145052000.L1A_LAC.server'
** Failed to determine/retrieve attitude and ephemeris files **
No attitude and ephemeris information available for this Aqua granule.
Processing cannot proceed; exiting.

exit_status=            1

When I use startnudge 5 it works as you suggested:

unix cmd =
$SEADAS/run/scripts/modis_L1A.csh /tmp/test3/MOD00.P2011145.0520_2.PDS -startnudge 5 -stopnudge 10; l1afile=ls -1t [AT]*.L1A_LAC | head -1; $SEADAS/run/scripts/modis_GEO.csh $l1afile -geocheck_threshold 95

It finishes fine.

scan: 390 out of 396 Wed May 25 11:31:45 2011
geogen_modis exit status: 0

Running validation test on geolocation file...
modis_geocheck.py A2011145052005.GEO 95 --verbose
Percentage of pixels with missing geolocation: 0.000000
Validation test passed for geolocation file A2011145052005.GEO
MODIS geolocation processing complete.

exit_status=            0

However, that first failure seems suspect in another way. If I:
w.get http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/PM1ATTNR_NRT.A2011145.0515.005 there is no problem.
So I am not too sure what the other issue is. While it doesn't __NEED__ PM1ATTNR_NRT.A2011145.0515.005,
it should be able to connect to the server and find it at least.

Brock

The connection issues is entirely separate....webserver and DB are not happy with each other
following a migration - our sys admins are currently in the process of rolling back to the older
hardware until this entirely unanticipated issue can resolved.

Sean

A modification was made to the database query for the attitude/ephemeris files that appears to resolve
the incorrect file selection problem.

Regards,
Sean

Thanks will try. Next problem identified here:
http://oceancolor.gsfc.nasa.gov/forum/oceancolor/topic_show.pl?tid=4039