[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20000914: ROUTE PostProcessing

>From: Tye Parzybok <address@hidden>
>Organization: Oregon State University
>Keywords: 200009142249.e8EMnCb02002 LDM ldm-mcidas batch.k


>I've been working with Wayne Gibson on the conversion from wxp to mcidas
>and as he mentioned previously, the conversion has gone well.  The next
>step we want to take is create the GOES-West IR/TOPO and VIS/TOPO
>composite images.

OK, this should be easy enough.

>I found the setup instructions in the support archives and am able to
>create the AREA024* and AREA025* files by running the NORTMAPR commands
>directly from mcidas.  From these, I'm able to create the images and they
>look great.

Excellent.  You are practically done.

>Now, I'm trying to have the AREA files created automatically
>using PostProcessing, but I'm having problems.
>I receive these messages in the ldm log file:
>pnga2area[4184]: Starting Up
>pnga2area[4184]: output file pathname: /home/ocs/ldm/data/mcidasd/AREA0123
>/bin/sh: batch.k: not found
>pnga2area[4184]: unPNG::  1562287   2439056  1.5612
>pnga2area[4184]: Exiting
>The result being no composite AREA files created.

The message "batch.k not found" is telling you a couple of things;

o the decoder, pnga2area, has read the routing table and has seen
  that it is supposed to run ROUTE PostProcess BATCH files

o the batch.k command file has not been found

>I have been using the mcidas routing scheme to create the ir/vis/wv
>images, so my ROUTE.SYS and SYSKEY.TAB files are in the proper decode
>directory with correct permissions.  I've made the necessary changes to
>the ROUTE table to enable the products to be created:
>N3 GOES-West IR/TOPO Composi  240-243 none none none 3
>N4 GOES-West VIS/TOPO Compos  250-253 none none none 3
>U5 GOES-West Western US IR    130-133  AREA0130  00258 2020 GW-VIS.BAT 3
>U9 GOES-West Western US VIS   120-123  AREA0120  00258 2020 GW-IR.BAT 3
>and the entries have been RELeased. (N3 & N4 don't show any file names
>because I've SUSpended and reRELeased them.)

Very good.

>I've made the necessary changes to batch.k in the ldm-mcidas distrubution:

In general, it is not a good idea to include the directory where the script
batch.k exists in the PATH in the script batch.k.  You correctly include,
however, the directory $MCGUI where the real McIDAS BATCH executable should
exist first in PATH.

> /ucblib:/usr/lib/X11:/usr/lib/X11:/opt/SUNWspro/SC5.

The LD_LIBRARY_PATH environment variable is generally not needed, but it
can't hurt.

>The batch.k script file currently resides in /home/ocs/ldm/ldm-mcidas/bin,
>but will eventually reside in /home/ocs/ldm/decoders/bin, to avoid being

Good.  I was going to suggest that.

>(even though we install new versions of ldm-mcidas in unique
>directories then create a ldm-mcidas symbolic link to the new

As you note, it is best to copy batch.k to a fixed directory.  That way
you only have to edit it to set McIDAS values once.

>Running "which batch.k" when logged in as the ldm user (ldm) returns
>/home/ocs/ldm/ldm-mcidas/bin/batch.k, so ldm apparently can find it.

Yes, but was the PATH in .cshrc updated before or after the LDM was
started.  If after, you need to stop and restart the LDM since the
environment variables that were in effect when it was started will be
the ones it uses.

>Running "which batch.k" when logged in as a mcidas user returns
>/home/ocs/mcidas/bin/batch.k, which would be accessable from the batch.k


>Some tests were made running under "at" to see what the path was
>to "batch.k" (so that the shell that ran the process started from scratch)
>and the file was found with no problem.

Excellent troubleshooting!

>The error message also doesn't tell me which batch.k can't be found, the
>script or the binary, or if batch.k can't find something.

This would be the script being not found.

>So I did an
>additional test: I put echo messages in the batch.k script to see if it
>was being executed, but no messages were produced.  So it appears that
>~ldm/ldm-mcidas/bin/batch.k can't be found.

The script batch.k sets up logging to the file $MCLOG.  If the script
gets run, then you should see some log output in that file.  By the
way, I have seen instances where the PATH specified in the script
batch.k did not include the location for 'sed'.  This is something to
check, but it is not the cause of the problem you are now

>I don't know if I've overlooked somthing or what to try next, but I would
>greatly appreciate any help you could give me.

The only thing that comes to mind, since you did a great job of
discerning what had to be done, is the possibility of the LDM having
already been running when the PATH in .cshrc was modified to add
/home/ocs/ldm/ldm-mcidas/bin.  If this is the case, the only thing that
should have to be done is the stopping and restarting of the LDM from
as session where 'which batch.k' results in /home/ocs/ldm/ldm-mcidas/bin.

Please let me know if this is not the case.  If necessary, I am quite
willing to login and take a look at your setup to see if something
jumps out at me.

>Thank you for you time,

Talk to you later...

>Joseph Smith
>Joseph I. Smith, Programming Assistant                      
>Oregon Climate Service               Voice: 541-737-8305   
>Oregon State University              Fax: 541-737-5710
>316 Strand Ag Hall                   E-mail: address@hidden
>Corvallis, Oregon USA 97331          Web: http://www.ocs.orst.edu

Tom Yoksas

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.