>From: Jim Koermer <address@hidden>
>Organization: Plymouth State
>Keywords: 200009121453.e8CErlb21144 ldm-mcidas PNG pnga2area
Jim,
>I was still having no success in getting things to work on my aix/rs6000
>box, perhaps still a binary problem. I kept getting the same stuff with
>no additional verbose output.
I a suprised by this. What version of AIX are you running?
>However, I was successful in getting things working on my FreeBSD
>server. At first, the verbose log was telling me that it couldn't find
>batch.k,
This is not an error per se. If one is using the McIDAS routing table
to name the ouput files (you are), and if the routing table has ROUTE
PostProcess BATCH file entries (yours apparently does), then after
decoding an image the decoder will try to run batch.k. The setup
for actually running ROUTE PostProcess BATCH files requires one to:
o copy the Bourne shell script, batch.k, that is distributed with
ldm-mcidas (in the binary distribution, this will be in the etc
directory), to a directory in the PATH of 'ldm'. This is typically
/usr/local/ldm/decoders, or /usr/local/ldm/util.
o edit the Bourne shell script file and set the McIDAS environment
variables to match your setup. McIDAS has to be installed in order
to run McIDAS PostProcess BATCH files, so all one needs to do is
specify where HOME for McIDAS is in batch.k. Also, one has to
specify where the McIDAS bin directory is so that the real McIDAS
BATCH command can be run from the script.
>so for the time being, I just copied it into ldm's bin
>directory
Hopefully, you mean the shell script, batch.k, that comes with the
ldm-mcidas distribution.
>and now the AREA files seem to be their normal sizes and have
>their normal mcidas filenames.
OK. The decoder is working, and is attempting to kick off the PostProcess
BATCH files.
>However, there are some log entries that I don't understand (see below).
>
>Here's a sample of the log file:
>
>Sep 15 00:38:47 pnga2area[71941]: Starting Up
>Sep 15 00:38:47 pnga2area[71941]: output file pathname:
>/data/mcidas-c/AREA0213
> datoff: 2816
> datlen: 2560
> cmtlen: 160
> rcond: 3
> batch.k BATCH UW 213 100259 1500 1 \"H2O8.BAT
>Sep 15 00:38:48 pnga2area[71941]: unPNG:: 160809 607776 3.7795
>Sep 15 00:38:48 pnga2area[71941]: Exiting
>Sep 15 00:44:06 pnga2area[72041]: Starting Up
>Sep 15 00:44:06 pnga2area[72041]: output file pathname:
>/data/mcidas-c/AREA0156
> datoff: 2816
> datlen: 2560
> cmtlen: 240
> rcond: 3
> batch.k BATCH UI 156 100259 1500 1 \"IR8.BAT
>Sep 15 00:44:07 pnga2area[72041]: unPNG:: 1011096 2422256 2.3957
>Sep 15 00:44:07 pnga2area[72041]: Exiting
>Sep 15 00:46:37 pnga2area[73017]: Starting Up
>Sep 15 00:46:37 pnga2area[73017]: output file pathname:
>/data/mcidas-c/AREA0140
> datoff: 2816
> datlen: 2560
> cmtlen: 240
> rcond: 3
> batch.k BATCH UV 140 100259 1500 1 \"VIS8.BAT
>Sep 15 00:46:38 pnga2area[73017]: unPNG:: 1377121 2422256 1.7589
>Sep 15 00:46:38 pnga2area[73017]: Exiting
This looks reasonable enough. The name of the BATCH file that is
attempting to be executed (H2O8.BAT, IR8.BAT, and VIS8.BAT) are
specified in the McIDAS routing table, ROUTE.SYS.
>Here other entries that I don't understand:
>
>Sep 15 00:47:18 pnga2area[73025]: Starting Up
>Sep 15 00:47:18 pnga2area[73025]: output file pathname:
>/data/mcidas-c/AREA1667196001
> datoff: 1280
> datlen: 1024
> cmtlen: 880
> rcond: 0
> batch.k BATCH CB 0 100258 230000 1 \"
>Sep 15 00:47:18 pnga2area[73025]: unPNG:: 87617 242800 2.7712
>Sep 15 00:47:18 pnga2area[73025]: Exiting
>Program terminated, segmentation violation
>Sep 15 00:48:28 pnga2area[73050]: Starting Up
>Sep 15 00:48:28 pnga2area[73050]: output file pathname:
>/data/mcidas-c/AREA1667196001
> datoff: 1280
> datlen: 1024
> cmtlen: 800
> rcond: 0
> batch.k BATCH CD 0 100258 230000 1 \"
>Sep 15 00:48:28 pnga2area[73050]: unPNG:: 87938 242720 2.7601
>Sep 15 00:48:28 pnga2area[73050]: Exiting
>Program terminated, segmentation violation
This is happening for the CIMSS products. The reason it is happening is
there are no entries in the routing table for the CIMSS products. You
need to add those entries by:
<login as 'mcidas'>
cd workdata
First check to make sure that the routing table is not damaged:
route.k LIST
If there is random garbage in the listing, then the routing table has
been damaged. If this is the case, a new one has to be created. Let
me know if this is the case, and I will step you through the recreation
process. Or, you can use the copy of ROUTE.SYS in the ldm-mcidas
distribution since it already has the CIMSS entries in it (located in
the etc directory of the ldm-mcidas distribution).
Next, add CIMSS entries to the routing table
ftp ftp.unidata.ucar.edu
<user> anonymous
<pass> your email address
cd pub/mcidas
get CIMSS.BAT
quit
batch.k CIMSS.BAT
After doing this, a routing table listing:
route.k LIST
will show entries for product codes CA, CB, CC, CD, CE, and CF. These
are the CIMSS products:
CA - Cloud Top Presure
CB - Precipitable Water
CC - Sea Surface Temperature
CD - Lifted Index
CE - CAPE
CF - Ozone
>Note during ths time, I received all I am getting the file
>"AREA1667196001" (referencesd in the log) written to the directory, but
>the GOES files all look okay.
This is due to lack of a routing table entry for the CIMSS products.
>Thanks for the help. When I get the time, I'll try to get a f77 compiler
>back on the rs6000 and then try building from source.
Again, I am suprised that the binary for AIX doesn't work. I built
the binary on our 4.3 machine, so if you are also running 4.3 things
should work right out of the box (modulo the CIMSS notes above).
If you would like me to take a quick look, please let me know (and
give me the McIDAS and LDM logins).
Tom
>From address@hidden Thu Sep 14 22:25:14 2000
>Subject: Re: 20000914: ldm-mcidas PNG decoder installation at Plymouth State
Unidata Support wrote:
> >From: Jim Koermer <address@hidden>
> >Organization: Plymouth State
> >Keywords: 200009121453.e8CErlb21144 ldm-mcidas PNG pnga2area
>
> Jim,
>
> >I was still having no success in getting things to work on my aix/rs6000
> >box, perhaps still a binary problem. I kept getting the same stuff with
> >no additional verbose output.
>
> I a suprised by this. What version of AIX are you running?
>
It's still back on 4.1.4. I actually have a later version and tried
installing a few times, but the installation seemed to hang after many
hours with no apparent activity. I tried getting help from IBM, but
they don't provide a lick of support unless you have a service
agreement for big $, even for a product that you purchase from them.
This was one very big reason why we went with FreeBSD on Dell
platforms. When that box dies, we most likely won't have it fixed. It
does network things like web serving and ldm pretty well, but it's now
a dog in running graphical applications.
>
> >However, I was successful in getting things working on my FreeBSD
> >server. At first, the verbose log was telling me that it couldn't find
> >batch.k,
>
> This is not an error per se. If one is using the McIDAS routing table
> to name the ouput files (you are), and if the routing table has ROUTE
> PostProcess BATCH file entries (yours apparently does), then after
> decoding an image the decoder will try to run batch.k. The setup
> for actually running ROUTE PostProcess BATCH files requires one to:
>
> o copy the Bourne shell script, batch.k, that is distributed with
> ldm-mcidas (in the binary distribution, this will be in the etc
> directory), to a directory in the PATH of 'ldm'. This is typically
> /usr/local/ldm/decoders, or /usr/local/ldm/util.
>
In the BSD install, it was in my /home/ldm/ldm-mcidas/bin directory.
>
> o edit the Bourne shell script file and set the McIDAS environment
> variables to match your setup. McIDAS has to be installed in order
> to run McIDAS PostProcess BATCH files, so all one needs to do is
> specify where HOME for McIDAS is in batch.k. Also, one has to
> specify where the McIDAS bin directory is so that the real McIDAS
> BATCH command can be run from the script.
The defaults matched our mcidas setup.
>
>
> >so for the time being, I just copied it into ldm's bin
> >directory
>
> Hopefully, you mean the shell script, batch.k, that comes with the
> ldm-mcidas distribution.
>
Actually, it was a copy of batch.k from /home/mcidas/bin, but I later
copied the one from the distribution mentioned above.
>
> >and now the AREA files seem to be their normal sizes and have
> >their normal mcidas filenames.
>
> OK. The decoder is working, and is attempting to kick off the PostProcess
> BATCH files.
>
I'll work on the CIMSS stuff tomorrow (make that later today).
Jim
--
James P. Koermer E-Mail: address@hidden
Professor of Meteorology Office Phone: (603)535-2574
Natural Science Department Office Fax: (603)535-2723
Plymouth State College WWW: http://vortex.plymouth.edu/
Plymouth, NH 03264
>From address@hidden Fri Sep 15 16:13:44 2000
>Subject: Re: 20000914: ldm-mcidas PNG decoder installation at Plymouth State
Tom,
> This is happening for the CIMSS products. The reason it is happening is
> there are no entries in the routing table for the CIMSS products. You
> need to add those entries by:
>
> <login as 'mcidas'>
> cd workdata
>
> First check to make sure that the routing table is not damaged:
>
> route.k LIST
I didn't seem to have one, but I copied the ROUTE.SYS from the
ldm-mcidas distribution and did the other steps below.
>
> If there is random garbage in the listing, then the routing table has
> been damaged. If this is the case, a new one has to be created. Let
> me know if this is the case, and I will step you through the recreation
> process. Or, you can use the copy of ROUTE.SYS in the ldm-mcidas
> distribution since it already has the CIMSS entries in it (located in
> the etc directory of the ldm-mcidas distribution).
>
> Next, add CIMSS entries to the routing table
>
> ftp ftp.unidata.ucar.edu
> <user> anonymous
> <pass> your email address
> cd pub/mcidas
> get CIMSS.BAT
> quit
>
> batch.k CIMSS.BAT
>
> After doing this, a routing table listing:
>
> route.k LIST
>
Gave me a good routing table, this time.
> will show entries for product codes CA, CB, CC, CD, CE, and CF. These
> are the CIMSS products:
>
> CA - Cloud Top Presure
> CB - Precipitable Water
> CC - Sea Surface Temperature
> CD - Lifted Index
> CE - CAPE
> CF - Ozone
>
They were there.
The logfile now generated by pnga2area now looks fine.
Thanks, Tom.
Jim
--
James P. Koermer E-Mail: address@hidden
Professor of Meteorology Office Phone: (603)535-2574
Natural Science Department Office Fax: (603)535-2723
Plymouth State College WWW: http://vortex.plymouth.edu/
Plymouth, NH 03264
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.