Ocean Color Forum - Not logged in
I use SeaDAS with runtime capabilities, and have encountered a few problems. Specifically, is it possible to:
- Call a SeaDAS batch script from the command line, specifying arguments (ie. seadas -em -b command_file variable1 variable2).
- Call a SeaDAS batch script from within another one.
I have not been able to do either of the above things, and am not sure if that is due to limitations with the runtime version of IDL, or incorrect syntax on my part. If those things are possible to do, it would be great to see a simple example.
Thank you very much.
To provide arguments to a seadas batch script a couple approaches are often used:
1) put the arguments in the environment and read the values using GETENV in the batch script
2) generate the script at run-time with the appropriate values set.
Thanks for the reply. My SeaDAS batch scripts are called by bash shell scripts. I have solved this problem by having my shell script write out a "parameter" file, with the variables defined in IDL syntax. The SeaDAS batch scripts read in these variables with the "readf" command. This works, but isn't very efficient in my mind.
It would be great to be able to construct an "include" file, which is an IDL file type that functions similarly to a "source" file in Unix. However I haven't been able to get that to work with SeaDAS runtime. Any insight into the limitations of runtime SeaDAS regarding this and similar capabilities would be great.
Also, as mentioned in the previous post, I have found it would be helpful to be able to call a SeaDAS batch script from within another one. However I have not been able to do so successfully. Is that possible with SeaDAS runtime?
Thanks a lot.
In your bash script, you can combine fragments of IDL code into a final batch script that is run by "seadas -em". So if you have a batch script, say "b.scr" that needs certain variables to be defined, you can make a second "a.scr" that defines the variables:
echo "a=1 & b=2" > a.scr
echo "print, a+b" > b.scr
cat a.scr b.scr > c.scr
seadas -em -b c.scr
I feel that this post is appropriate for this thread.
As previously noted I am writing SeaDAS batch scripts which are used to load various file types (Level-3 SMI, Level-3 Binned, Level-2, etc.) and output their bands as various file types (png, kmz, flat, hdf, etc.). I am writing these scripts so that they adhere to the SeaDAS runtime syntax (inclusion of & $) so that others may run them without an IDL license.
- Can a SeaDAS batch script written for runtime SeaDAS theoretically run on a system that is not using an embedded IDL license, but is instead using a purchased one? The reason I ask is that I attempted to run my runtime scripts using my purchased IDL license and got the error "Program code area full". There is a bit about that error here: http://www.astro.virginia.edu/class/oconnell/astr511/IDLresources/idl-faq-ivsoft-v4.html#T15.
- As a side note, the above error is interesting considering how I have spent the past two days attempting to debug one of my scripts. In a nut shell, the error seemed to coincide with going above a threshold # of lines of code (~ 600). Below that threshold the script ran, above it it errored. At a loss I decided to run the script on a different system and it ran fine. Any ideas on what could be going on here? The first system I was using is a Desktop running Ubuntu 10.04 with 8GB of RAM. The second one (on which the script worked) is a Macbook Pro with 2 GB of RAM. Could there perhaps be a difference between the systems that allowed more code to be compiled on my Macbook?
Thanks a lot.
In my lab we have many seadas scripts that run with embedded IDL on systems without IDL installed and also work using an IDL license. Some even work in gnudatalanguage if you arrange to populate the BN and RN variables and then save the "result" variable.
Memory problems used to be big issue when working with multiple bands on systems with 512M RAM, but I haven't run into either
"Unable to allocate memory" or "Code Area Full" errors in years.
In my experience, linux is not nearly as frugal with memory as legacy unix and Apple (see below). There may well be some limit to the size of a user band script. I generally breakup complex processing into functions and procedures so don't use embedded IDL -- the trick here is to make sure all the simple routine processing is done with embedded IDL so I can get a license for the stuff that is too complex for embedded scripts.
I did some tests using 2005180.L3b_DAY_CHL.main and S2005180.L3b_DAY_RRS.main
You can put "print, memory()" in a script to find out how much memory is being used. On my Macbook Pro (32-bit SeaDAS), 2 bands (chlor_a mean and variance) at 4320x2160 show "current" = 228MB, "peak" = 290MB. while 64-bit linux (RHEL 5.6) gave 276 and 332, respectively. If I add the 16 Rrs_ mean and variance products (2+result+16 bands), the Mac shows 860 and 900MB, while the linux system fails with a popup "BadAlloc (insufficient resources ..)".
I really appreciate all the advice you have given.
I was not able to decipher the problem. However, it couldn't help that my script was so long. So I think I have figured out a way to break it down into smaller scripts, and still allow people to use SeaDAS runtime. I am certainly looking forward to the introduction of SeaDAS 7.0 so that I won't have to deal with IDL anymore.
You are welcome to the advice -- I find it is really helpful to get this stuff onto the forum so I can refer colleagues to it even though they are many time zones away.
Be careful what you wish for -- legacy tools like IDL that started out when memory and CPU were expensive are often more careful about resource consumption than modern tools. You may find the time you spent justifying expenditures for IDL licenses is going towards justifing expenditures for hardware upgrades.