Ocean Color Forum - Not logged in
I just installed SeaDAS 6.2 on a VMware virtual machine as outlined on the setup page.
I am unable to process a L2 file from a L1B file and the terminal window shows the following:
seadas@seadas-vm:/disk01/seadas$ seadas -em
IDL Version 7.0 (linux x86 m32). (c) 2007, ITT Visual Information Solutions
% Embedded IDL: NASA GSFC SeaDAS Development, SeaDAS.
% Embedded IDL: NASA GSFC SeaDAS Development, SeaDAS.
SeaDAS Version 6.2 Update 2 (pid = 13317)
Detected a high-resolution file.
Executing: $SEADAS/run/scripts/getanc /disk01/seadas/seadas/A2005100111500.L1B_LAC -no-no2
Determining pass start and end times..
Input file : /disk01/seadas/seadas/A2005100111500.L1B_LAC
Start time : 2005100111500
End time : 2005100111949
Created 'A2005100111500.L1B_LAC.anc' l2gen parameter text file:
- All optimal ancillary data files were determined and found on local disk. -
Created L2GEN parameter file: /disk01/seadas/seadas/A2005100111500.L2_LAC.par
/bin/bash -c "l2gen par=/disk01/seadas/seadas/A2005100111500.L2_LAC.par"
And when I try to display the L2 file I get this:
GENERIC_FILE_TYPE detected a non-HDF file.
GENERIC_FILE_TYPE detected a SEAWIFS L0 file.
GET_SWF_L0_DATA : First record greater than last scan line.
I had to download update_01 and copy the ephtobin into run/bin3 to be able to generate a geo file properly, so I'm guessing that I'm missing something else and that its stopping the L2 processing from working.
If that's the problem, I'm not sure what it is exactly that I am missing.
Any help would be appreciated!
the exit status from the l2gen command suggests it completed successfully.
The "GENERIC_FILE_TYPE detected a non-HDF file" message suggests
that you're not loading in an HDF file - which, if l2gen did complete
sucessfully, you'd have an HDF file...
Could you run the following commands in a terminal window and post the output:
1) file /disk01/seadas/seadas/A2005100111500.L2_LAC
2) ncdump -h /disk01/seadas/seadas/A2005100111500.L2_LAC
The output of (1) should be: Hierarchical Data Format (version 4) data
if it's not, no need to run (2).
Thanks for your response. This is what I get:
seadas@seadas-vm:/disk01/seadas/seadas$ file /disk01/seadas/seadas/A2005100111500.l2_LAC
/disk01/seadas/seadas/A2005100111500.l2_LAC: ERROR: cannot open `/disk01/seadas/seadas/A2005100111500.l2_LAC' (No such file or directory)
I also just realized that the file that I was trying to load before as the L2 file was the par file, so I guess there was no L2 file generated at all.
Check your capitalization:
A2005100111500.l2_LAC != A2005100111500.L2_LAC
Sorry about that.
I still get:
seadas@seadas-vm:/disk01/seadas/seadas$ file /disk01/seadas/seadas/A2005100111500.L2_LAC
/disk01/seadas/seadas/A2005100111500.L2_LAC: ERROR: cannot open `/disk01/seadas/seadas/A2005100111500.L2_LAC' (No such file or directory)
Well, what is there?
ls -l /disk01/seadas/seadas
You could try running the l2gen process again, but this time run it in background and specify an output file and post it here.
seadas@seadas-vm:/disk01/seadas/seadas$ ls -l
-rw-r--r-- 1 seadas seadas 58582877 2011-06-01 01:00 A2005100111500.GEO
-rw-r--r-- 1 seadas seadas 552093839 2011-06-01 01:00 A2005100111500.L1A_LAC
-rw-r--r-- 1 seadas seadas 331530507 2011-06-01 07:02 A2005100111500.L1B_LAC
-rw-r--r-- 1 seadas seadas 2962 2011-06-02 11:52 A2005100111500.L2_LAC.par
drwxr-xr-x 5 seadas seadas 4096 2011-06-02 08:56 build
drwxr-xr-x 5 seadas seadas 4096 2011-06-02 08:55 config
drwxr-xr-x 2 seadas seadas 4096 2011-06-02 11:46 files
drwxr-xr-x 2 seadas seadas 45056 2011-06-02 08:57 idl_lib
drwxr-x--- 4 seadas seadas 4096 2011-06-02 08:57 idl_rt
-rw-r--r-- 1 seadas seadas 2960 2011-06-02 11:51 l2gen.par
drwxr-xr-x 7 seadas seadas 4096 2011-06-02 08:57 run
When I run it in the background and try specifying an output file nothing happens either except for generating a par file.
Sorry, I meant to say Logfile.
In the "SeaDAS MODIS L2 File Generating Program" window, the last text box is for "Logfile (Run(BG) only)", "/dev/null" by default. Erase that and enter some filename, then click on "Run(BG)". You may then quit SeaDAS, and check your logfile for progress. You can also enter "ps x | grep l2gen" to see if it's still running in background.
Here's the logfile.
Weird that it ends so suddenly.
Try this on the command line:
ls -l `which l2gen`
l2gen par=/disk01/seadas/seadas/A2005100111500.L2_LAC.par > l2gen.log 2>&1
I notice also that you're using SeaDAS Version 6.2 Update 2
You might want to install the latest update
SeaDAS Version 6.2 Update 2a
Thanks, I'll update it.
This is what I get:
seadas@seadas-vm:/disk01/seadas/seadas$ ls -l 'which l2gen'
ls: cannot access which l2gen: No such file or directory
seadas@seadas-vm:/disk01/seadas/seadas$ l2gen par=/disk01/seadas/seadas/A2005100111500.L2_LAC.par > l2gen.log 2>&1
The l2gen.log is empty file
When I do 'which l2gen' I get this:
seadas@seadas-vm:/disk01/seadas/seadas$ which l2gen
Looks like you used single quotes instead of backticks the first time.
After you've updated,
ls -l /home/seadas/seadas/run/bin/l2gen
yes I did use single quotes, my bad.
This is what I get:
seadas@seadas-vm:/disk01/seadas/seadas$ ls -l /home/seadas/seadas/run/bin/l2gen
-rwxr-xr-x 1 seadas seadas 7619981 2011-04-07 14:39 /home/seadas/seadas/run/bin/l2gen
seadas@seadas-vm:/disk01/seadas/seadas$ file /home/seadas/seadas/run/bin/l2gen
/home/seadas/seadas/run/bin/l2gen: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped
That should be the right executable & version. It still doesn't work? I may need to call in my boss to figure this out.
No it still doesn't work...
Thanks for looking into this!
I've been doing a good amount of l2gen on both MODIS and SeaWiFS, and have gotten the process down pretty well. I'd like to try to help you, if I can.
I downloaded the same MODIS A file you've been working with and put it on my system.
Since you're working in the VA (which I've been doing on some of my systems) you should check the disk space and what's mounted where.
Please do the following:
$ cd ~
$ mount >& mount.log
$ df -h >& df.log
Call those output files what ever you like, and post the results. Mount tells you which physical disk is mounted on what directory, and df = 'disk full' (with the -h option = human-readable) tells us how much space is used/available on the disks.
It may be that you don't have enough space to create the output file, which could cause the strange behavior of the system. I noticed that on the default VA installation, since the ancillary data gets placed right into the seadas installation directory, using up some valuable space in the already tight VA system (~7-8 Gb). I have set my ancillary data directory on my systems to a folder on a large file system.
When you share windows directories into the VA (under vmware), they get mounted automatically under /mnt/hgfs/YOUR_DIRECTORIES.
Try that and we'll see where to go from there. MODIS processing is tricky since it expects the shell to be CSH and not bash, and I've discovered bad behavior on some scripts on some systems.
Other problems may be related to script issues, so I run things from the command line and sometimes debug the scripts. I can help you with that after you've checked your disk space.
The disk space could be an issue, if the VA was downloaded prior to the release of update_02 for SeaDAS6.2
At that time the VA was increased to 120GB max size (up from the 8 previously).
What would also help diagnose the problem would be to run l2gen directly from the command line - this will
ensure something meaning full will be seen on the terminal window
Easy to do singe since you already have
a parameter file
In addition to the suggestions from Daniel , at a terminal window type:
l2gen par=<parfilename> >& l2gen.log
(where <parfilename> is replaced by the full path to the parameter file)
and the post the log file
Thanks for your feedback!
The l2gen.log is empty though, I ran your suggestion in the command line:
seadas@seadas-vm:~$ l2gen par=/home/seadas/seadas/A2005100111500.L2_LAC.par >& l2gen.log
I'm guessing that that's not what was supposed to happen?
Okay, so there's plenty of disk space. Also, you must've been able to write to that directory, since the par file and GEO files were created there.
You can try the l2gen command without any arguments:
and it should give you a large help output.
If you run the GEO generation manually, you could regenerate the GEO file, and see if there's any indication there was an error when it was generated. Based on your directory listing, I'm presuming the GEO file was generated from an L1A file and then the L1B file was also created by SeaDAS.
First, lets get some more diagnostics:
$ env >& environ.log
post the file environ.log
I usually go back to the original L1A file and start from scratch. You must be working in the directory where the files are so:
$ cd /disk01/seadas/seadas
$ modis_GEO.csh A2005100111500.L1A_LAC -disable-dem >& geo.log (for Aqua, do not use terrain elevation correction)
... output results
$ modis_L1B.csh A2005100111500.L1A_LAC A2005100111500.GEO >& l1b.log
and post the geo.log and l1b.log files.
Now you should have the GEO file, the L1B_LAC, L1B_HKM and L1B_QKM files.
After this, try running l2gen again
$ l2gen par=A2005100111500.L1B_LAC.par (par file will be in the current directory)
Note that you may edit the par file and change the paths to the input and output files as you see fit for testing purposes.
This may appear somewhat tedious, so I do apologize. However, both Sean and I know that it would be great if we were able to log into your system to see for ourselves what is happening. I lieu of that, we must have some diagnostics, and the more the better! So, listings, permissions, environment variables, paths, all matter in this case.
When you execute a shell, you may use the debugging output, which I will frequently do:
$ csh -xvf /home/seadas/seadas/run/scripts/modis_GEO.csh A2005100111500.L1A_LAC -disable-dem >& really_big_GEO_debug.log
$ csh -xvf /home/seadas/seadas/run/scripts/modis_L1B.csh A2005100111500.L1A_LAC A2005100111500.GEO >& really_big_L1B_debug.log
The '-xvf' options tell us exactly what the script thinks it's doing. The 'l2gen' program is a binary, however, and thus is more difficult to diagnose in terms of why it's failing. I would suspect an environment variable or path problem, or permission problem, and perhaps a corrupt input file (such as the L1B or GEO files). The SeaDAS GUI is supposed to handle everything automatically, and it works fine, but there's something else going on here. I'll look forward to seeing the output of the "env" command. If this is all too complicated, just let me know and we'll try another approach.
Thanks again for your feedback!
When I enter l2gen in the terminal I don't get a help output, I get this:
I think everything went fine until I tried the l2gen command
seadas@seadas-vm:~/seadas$ l2gen par=A2005101102000.L1B_LAC.par
Here are the l1b.log, geo.log, and environ.log
Thanks for taking a look at this...
I'm thinking you have a broken binary file for l2gen :p
So, I'm going to try to point you to a copy of l2gen.
download the file ftp://samoa.gsfc.nasa.gov/seadas/seadas/updates/update_02_linux.tar.gz
(save the file to /home/seadas)
$ tar zxvf update_02_linux.tar.gz
$ cp update_02/run/bin/l2gen /home/seadas/seadas/run/bin
This should work now!
If this does work, I would suggest doing a re-install of seadas within the VA itself, by gathering up the seadas installation files you need, then doing an install as if you were on a "normal" 32 bit linux machine. I've done this in my VA.
You should move the /home/seadas/seadas folder to /home/seadas/seadas_orig.
Then make a new directory seadas, cd into the new directory, and untar all the necessary seadas installation stuff there. Then run config/seadas_setup from the /home/seadas/seadas folder, and set up the system. Follow that with updates #1 and #2.
Then test the new seadas installation, and if it's working as it should, remove the /home/seadas/seadas_orig (recursively) :
$ rm -rf seadas_orig
Take a look at the following lines I noticed in Lauren's env.log file:
The 'dastrunk' path member seems to be some kind of residual from a repository.
Perhaps a bug in an install script somewhere where seadas/trunk got munged up?
copy and paste and execute the following, then try l2gen again :
$ export TERRA_QA_LUT=/home/seadas/seadas/run/var/modist/cal/EVAL/MOD02_QA_LUTs.V184.108.40.206.hdf
$ export TERRA_EMIS_LUT=/home/seadas/seadas/run/var/modist/cal/EVAL/MOD02_Emissive_LUTs.V220.127.116.11.hdf
$ export TERRA_REFL_LUT=/home/seadas/seadas/run/var/modist/cal/EVAL/MOD02_Reflective_LUTs.V18.104.22.168.hdf
It is indeed. When testing to make sure all worked prior to packaging,
I test the modis_update_luts.csh script, which overwrote the $SEADAS with
the path defined by $SEADAS on the test machine....
The simple fix is to run the $SEADAS/run/scripts/modis_update_luts.csh
script after installing SeaDAS.
I've tried all your suggestions and reinstalled SeaDAS within the VA, and l2gen still doesn't work. Maybe its the VA itself that's the problem?
Very strange. What is your VA exactly? Did you build one of your own (sounds like you might have), or use the one from the SeaDAS downloads? Make sure you're running 32 / 64 bit SeaDAS depending on the architecture of your VA. So, let us know what the distribution/architecture of the VA is.
At this point, I'd go so far as to suggest buying another hard drive ($70) 2Tb and put it in your computer, install a 32 or 64 bit "real" Linux distro, install and and run SeaDAS on that.
Or, if you have a free disk (mostly empty), copy everything off it onto another Windows disk, then do a Linux install (perform the install to the available space).
Otherwise, debugging the VA will be the course of action. The VA is handy, but I'd choose a "native" install over the VA, given the choice.
I installed linux on a disk and SeaDAS is up and running. Thanks for the advice!
You're welcome, Lauren!
Happy to be of help. You'll have fun now with that setup. I think all the SeaDAS developers (I'm just a user/contribute where I canner...) appreciate when someone has everything working the way it's meant. (eh, Sean, and B.Franz, SAIC folks, Hughes, and everyone else ..?)
Good Luck, and Happy DAS mining!