I've been running Seadas 4.9 via a shell script and have tried using the following command to go from L1B to L2 for an Aqua dataset:-

msl12 sat_id=4 ifile=<path to ifile> geofile=<path to geofile> ofile=<path to ofile>

Result .....No processing

If I leave out the 'sat_id=4' then the dataset processes.  Ive also tried just using 'msl12 4 ifile=<path to ifile> geofile=<path to geofile> ofile=<path to ofile>' ..again with no success. 

The questions are...does the msl12 program require sat_id to be quoted as per the paragraph on command line processing in the msl12.html documentation?  or  Does the msl12 program pick up the satellite id from the filename ie A?????????????.L1B_LAC ??

The reason for the question is that an image viewing/processing system we use  reports the following:-

Extracting CoreMetadata...
...CoreMetadata.0 - missing
...attribute[ASSOCIATEDPLATFORMSHORTNAME] - missing
...attribute[Sensor Name] - MODIST
...platform TERRA sensor MODIS
Parsing date/time information...
...attribute[RANGEBEGINNINGDATE] - missing
...attribute[Start Year] - OK
...attribute[Start Day] - OK
...attribute[Start Millisec] - OK
...attribute[End Year] - OK
...attribute[End Day] - OK
...attribute[End Millisec] - OK
Parsing day/night information...
...attribute[DAYNIGHTFLAG] - missing
...attribute[Day or Night] - Day

I'm wondering whether it is because I have ommitted the 'sat_id' when the data was processed?

Thanks in advance for any help

Regards

Mike

Hi, [the below script should help]
I do not know how much you know about script, but this is the code I used to process from L1B to L2.
I do not use the sat_id=4, just a 4.
If you have any question about the below script let me know.

infiles=findfile('/home/William/ModisL1B/A200*.L1B_LAC')
ingeofiles=findfile('/home/William/ModisGeo/A200*.GEO')
n = n_elements(infiles)
for i=0,n-1 do begin & $
print,' processing file: ',infiles(i) & $
print,' processing geofile: ',ingeofiles(i) & $
msl12, 4, ifile=infiles(i), geofile=ingeofiles(i), $
ofile1= infiles(i)+'.L2_LAC', $
l2prod1='chlor_a,sst,calcite,ipar,tsm_clark,poc_clark,l2_flags,flh,nLw_412,nLw_443,nLw_488,nLw_531,nLw_551,nLw_667,nLw_678,nLw_748,nLw_869',/wait & $
endfor

Hi Zaro,

Thanks for the reply,  I'm processing DB files so I'm carrying out the operation on single data sets as they come in which means that I don't need to chain process lots of of L1B files at a time.  This should make it easier you would think....!  I've tried using 'msl12, 4, ifile=..." etc (constructed the same as your script) but it still bombs out. Yet if I leave out the '4' after the msl12, the L1B file processes OK...

Mike,

At first I thought maybe you were running a shell script and calling msl12 directly as a unix binary, but I see from your script that it is actually an IDL(seadas) script instead.  The seadas script syntax for calling msl12 is correct as it is in your script, and you are correct that the sat_id argument should just be a number and not in quotes, like:

msl12, 4, .......

The one inconsistency that stands out for me is that your metadata seems to indicate that this is a Terra file, as opposed to Aqua.  I don't know whether you have given results from different processing runs, which may explain that inconsistency, or whether you have inadvertently misnamed a Terra file as an Aqua file.  If the file is actually Terra data, you would want to supply a "5" as the sat_id, like:

msl12, 5, .....

Mark

Ah, okay, I see now that the first two posts were from different users, which was confusing me.  So the question would remain, whether you are running a shell script, or an IDL script?

Mark

What Mark is saying is 100% true, make sure if is Terra is 5 and if Aqua is 4.

The below is the sat_id number for each sensor,          see: http://oceancolor.gsfc.nasa.gov/seadas/doc/msl12/msl12.html
0=SeaWiFS, 1=OCTS, 2=MOS, 4=Aqua, 5=Terra, 6=CZCS

Hi Guys,

Thanks for the input, in answer to your points... Yes it is an Aqua dataset as per my original post..The viewing program seems to have wrongly 'guessed' that it is Terra, probably because it is looking for the missing coremetadata for the info and Terra may be the default option.

Mark,
Yes I'm running it under a cshell script that takes the process through direct data capture, batch process through RTSTPS then L0_to_L1AGEO, L1A_to_L1B and finally, msl12.  To ensure that the seadas output is compatable with the present viewer system, I snag the start stop times into a logfile and use them to rename the L1B and L2 products to the IMAPP output format naming convention once the processing is complete.

The thing that is bugging me is why I can't get the msl12 to recognise the sat_id.  If I run it through the gui, I can see that the command in the shell window being used is 'msl12, 4,...etc' but it doesn't appear to work in the cshell script...I have to leave out the sat_id. 

I think the 'coremetadata' thing is a red herring because it is not present even in the gui produced L2 products (product viewed using HDF Explorer).  I'll have a talk with the writer of the viewer because he can pick up the coremetadata from any of the L1B products instead of looking at the L2 product for it.

Zaro,
Re. my answer to Mark above, I pick up whether the L1 products are starting with 'A' or 'T' as part of the c shell script and from that derive the sat_id number.  Thanks for the info anyway.

Regards

Mike

Mike,

Concerning the viewing program wrongly guessing that it is Terra data because of the missing coremetadata, if you are trying to view the level 2 file, then no it will not find the "coremetadata" in the level 2 since the format of the metadata changes at level 2 to an ocean color format.  The "coremetadata" is only found in the level 1b and prior.  You can view the metadata of the level 2 file using an HDF utility included within seadas called "ncdump", which is located in the $SEADAS/hdf/HDF4/bin directory.  A typical invocation would be:

$SEADAS/hdf/HDF4/bin/ncdump -h <filename>

When running msl12 with a c-shell script, you would probably be directly calling the unix msl12 binary, in which case there is no "sat_id" argument recognized.  The sat_id argument is strictly a seadas command-line argument.  We are in the process of taking out that sat_id argument in our upcoming release, as it seems to cause more confusion than it's worth.

Regards, Mark

Mark,

Thanks for the info, it fits in with all the above....Will the sat_id arguement still be in v5.0 when it comes out? 

Regards

Mike

Mike,

No, the sat_id argument will be removed in 5.0.

Mark

Thanks Mark