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

19990302: Colgates Mcidas-X 7.40

>From: Adam Burnett <address@hidden>
>Organization: Colgate
>Keywords: 199902171421.HAA02538 McIDAS make Fortran

Adam,

>Just a note to tell you that my installation of Mcidas-x 7.40 seems to have
>worked well.  I have just a couple of additional issues I'm trying to
>resolve.  
>
>As it turned out, I needed to add another couple of GBs worth of hard disk
>to my machine to handle all the products that I'm set to receive.  With
>that, I had to redefine my mcidas storage and xcd storage area from what I
>had told you before.  Now, my xcd decodes files to: /data3/xcd

OK.

>My mcidas decoder write files to: /data3/mcfiles
>
>The user ldm has its home directory on: /data2/ldm
>
>The mcidas user has its home directory on: /data2/mcidas
>
>Issue 1:  Trouble with the lwfile decoder.  Below are a couple of lines from
>my pqact.conf file.  
>
>MCIDAS ^(GUNRV2 .*)    PIPE    -close
>/data2/ldm/ldm-mcidas-7.4.0/bin/gunrv2 -d /data3/mcfiles
>#
>MCIDAS ^(LWFILE .*)    PIPE    -close
>/data2/ldm/ldm-mcidas-7.4.0/bin/lwfile -d /data3/mcfiles
>
>
>The gunrv2 decoder works OK (as does my lwtoa3) but the lwfile decoder
>generates errors in my ldm log files.  A sample of the log is:
>
>Feb 25 15:36:19 gissun lwfile[2029]: PRODUCT CODE=US          99056
>Feb 25 15:37:57 gissun lwtoa3[2032]: PRODUCT CODE=UC          99056
>Feb 25 15:38:10 gissun lwtoa3[2032]:  Done -- AREA= 61
>Feb 25 15:38:40 gissun pqact[1632]: pbuf_flush (33) write: Broken pipe
>Feb 25 15:38:40 gissun pqact[1632]: pipe_dbufput:
>4.0/bin/lwfile-d/data3/mcfiles write error
>Feb 25 15:38:40 gissun pqact[1632]: pipe_prodput: trying again
>Feb 25 15:38:40 gissun pqact[1632]: pbuf_flush (33) write: Broken pipe
>Feb 25 15:38:40 gissun pqact[1632]: pipe_dbufput:
>4.0/bin/lwfile-d/data3/mcfiles write error
>
>Any thoughts?

Perhaps there is a file with the same name as what 'lwfile' wants to write
to in the output directory that does not have write permission for the
user that is running the LDM?

The other possibility is that the routing table entry for the LWFILE
product is SUSpended.  In this case, the LDM starts up the 'lwfile' decoder
which then reads the routing table and sees that it is not supposed to
decode the product, so it exits.  When the LDM starts up 'lwfile' it opens
a pipe through which it will feed 'lwfile' the product it has received.
If 'lwfile' goes away without reading from the pipe (or if it stops reading
from the pipe before the entire product has been read) the LDM will emit the
"Broken pipe" error message.  This is the most likely cause of the message
you relayed.

>Issue 2 - The Unidata GUI
>
>I've been running the Unidata GUI (as well as the Fkey menu).  When I try to
>contour model grids with the Unidata GUI I get an error:
>
>Function not yet implemented: GRIDPLOT

That is correct; I have not yet implemented the Tcl/Tk procedure for
plotting grids in my GUI.

>Is this function really not yet implemented or is it something that I did
>wrong in setting up my system.

You did nothing wrong.

>Issue 3 - My /data2 filesystem, which houses the ldm and mcidas users, has
>been slowly filling up.  I have my /data3 partition, which contains the xcd
>and mcidas files, under control (I think) with the mcscour.sh cron and the
>Mcidas scheduler (which I still am a bit fuzzy on).  

When running on a Unix system, the best way to scour McIDAS products is
to run the 'mcscour.sh' script (installed in the ~mcidas/workdata directory)
from a cron entry run by 'mcidas'.  Before running 'mcscour.sh', you will
have to edit it and set MCDATA, MCPATH, etc. to match your system setup.
When this is running, you no longer need to use the McIDAS scheduler for
scouring activities.  This then allows you to not have to run McIDAS all
of the time.

>When I looked around the /data2 filesystem for reason why the system is
>filling up, I came across a bunch of stuff under /data2/ldm/data.  Upon a
>review of my pqact.conf file I realized I had an entry that is:
>
> WMO   ^([^H][A-Z])([A-Z][A-Z])([0-9][0-9]) (....) ([0-3][0-9])([0-2][0-9])
>       FILE    data/\2/\4/\6/\1\2.wmo

OK.

>In all of my exploits, I can't seem to remember what this WMO line is all
>about or how it got there - gremlins?

No, not gremlins.  This line will save all products that match the regular
expression into undecoded data files.  Many sites like to do this since
they like to have the unadulterated data available.

>I suspect it's responsible for a lot
>of stuff being written to the data folder in my ldm user.

Right.

>Could this be
>responsible for my filesystem filling up?

Yes.

>What is the WMO stuff?

The feed type in pqact.conf names the data stream.  WMO is actually the
collection of the various types of data in the NOAAport (formerly FOS)
stream (including gridded products).  MCIDAS indicates the Unidata-Wisconsin
datastream; NLDN indicates the lightning data stream from SUNY Albany, and
so on.

>How can I make use of it?

This is too large of a question to answer without knowing what your objectives
really are.

>Should I be making use of it?

It is up to you, but probably not, at least not right now.

>How can I scour it?

Don't write it in the first place.  In order to disable this, all you need
to do is edit pqact.conf and comment out the lines above and then send
a HUP to the pqact process telling it to reread its configuration file
(which is pqact.conf).  If/when you do this, you should immediately look
at the last several lines of the LDM log file (~ldm/logs/ldmd.log) to
make sure that there are no errors.  If when making the mods you had a typo,
you could cause pqact to not run at all.  In this case, you will need
to reedit pqact.conf and correct the typo and then resend a HUP to the
pqact process.

>Thanks Again

Talk to you later...

Tom

>From address@hidden  Tue Mar  2 10:41:51 1999

>Tom,
>Thanks for all the good stuff.  I will put it to work right away.
>Adam