Re: Running LAS with GrADS as the visualization program

[Joe Sirott <sirott@xxxxxxxxxx>]

Hi Jennifer,

I'm assuming that you're running a version of GrADS that is not publicly available (since the Linux version 1.7 doesn't support the printim command), which means I can't verify your problems...

I did try your script using GrADS version 1.7 and adding an "enable print command", removing the "printim" command and substituting, after closing GrADS, a call to the gxpng program. It worked.

Here are a few things to look at:

1) Has the GrADS command line prompt changed? In version 1.7, it's 'ga->'; in your code the CLC module constructor is set to look for a 'ga>' prompt. An incorrect prompt line string will cause CLC to hang (and eventually timeout). This might account for your Plan A problems.
2) Your Plan B will always fail, because the CLC module will get a signal indicating that the child process (GrADS) has died unexpectedly (as you discovered).
3) Not sure why Plan C doesn't work for you -- seems like some kind of timing problem (perhaps the child process is notifying the parent process that it has finished before all of the write buffers have been flushed). If you're not going to use any of the CLC machinery for communicating with a child process , it would probably be easier to just use the "system" call in Perl to execute GrADS. Or, you could put in a small delay after the call to "close" to make sure all buffers have been flushed. The select command works well for this. For a 100 ms delay, for instance, use select(undef,undef,undef,0.1)
4) LAS comes with a script named "testCLC.pl" which exercises the CLC machinery for Ferret from the command line. If you want to experiment with the CLC connection to GrADS without having to go through all of the other LAS machinery, you can easily modify this script.

"Jennifer M. Adams" wrote:

Dear LAS Users and Experts,

I am trying to reconfigure the LAS to use GrADS as the "back
end" visualization program instead of Ferret. We are running
LAS on an intel machine running Redhat Linux 7.0. We have
successfully installed the whole business using the RPMs
provided by Zhangfan Xing. I can get it to work perfectly
with a Ferret data set (the COADS Climatology) but I have
been unsuccessful in getting it to display a GrADS image.

Based on numerous trials and tribulations and extra
statements printed to the GenericLASdebug.txt file, I have
narrowed the problem down a bit. The CLC module spawns the
child process that runs GrADS, but I never get to the point
where it sees the command line prompt and the 2-way
communication pipe is established. There's a 'select'
command in the 'synch' subroutine in CLC.pm that hangs and I
get 'timeout' error messages.

I devised a test to see if the problem was with my GrADS
executable. I wrote a small C progam called fauxgrads.c
which reads in some args from the command line, writes them
back out and then issues a command line prompt just like the
GrADS prompt. If the user enters 'quit' at the prompt the
program quits, otherwise it returns a new prompt. If I
substitute my little program instead of grads, I get the
same results.

Plan B is to fire up GrADS with the option of executing a
script immediately. I dump all the necessary commands to a
script file, and then feed that file name to GrADS as I
start the execution. Included in the GrADS script are the
commands to set the lat/lon/lev/time constraints, display
the variable, dump the image from the graphics buffer into
the uniquely-named gif file in the output directory, and
quit. With this technique, there is no need to establish the
2-way communication between the LAS and GrADS, because GrADS
does everything it needs to do and quits all in one easy
step. The problem is, the CLC module assumes this is an
error and I get the "program quit unexpectedly" message and
the image is not displayed.

Plan C is the same as Plan B except I remove the call to the
wait_for_prompt subroutine. My intent is to keep it from
ever trying to 'synch' with the child process and thereby
skipping over the 'program quit unexpectedly' errors and
just continue with the business of displaying the image. But
for some reason, this doesn't work and I get a "Not Found"
error message in the display window. The error message
contains the uniquely-named gif file it's trying to display,
which is consistent with the filename written to the GrADS
script file. If I execute GrADS with this script file
outside of the LAS, the image is created without a problem
and if I then hit the 'reload' button in the display window
the image comes up.

I suspect that the problem with Plan C is that merely
omitting the call to 'synch' (actually, it's
'wait_for_prompt' which calls 'synch') is not the proper way
to tell the the LAS that we don't need the 2-way
command-line interface with GrADS. I have attached the chunk
of perl code that I'm using
-- it's basically a modification
of the Grads.pl file that comes with the LAS distribution.

If any of the LAS developers could take a look at the file
and help me simplify it properly, I'd be most grateful. And
if any of the other LAS users out there have tried this
before and been able to successfully change the back-end
visualization program, I'd be delighted to hear how you did
it.

Respectfully submitted,
Jennifer

P.S. My LAS URL is http://192.239.84.113:8001/las/
--
----------------------------------------
Jennifer Miletta Adams
Center for Ocean-Land-Atmosphere Studies
4041 Powder Mill Road, Suite 302
Calverton, MD 20705-3106
Phone: (301)902-1278 or (301)595-7000
Fax:   (301)595-9793
Email: jma@cola.iges.org

  ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
                Name: custom.pl
   custom.pl    Type: Perl Program (application/x-perl)
            Encoding: 7bit

--
Joe Sirott