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

20010801: LDM gempak write errors



>From: "Wayne Bresky" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200108011236.f71CaG111227

>Steve,
>
>I was a bit confused by your second paragraph.  It was my understanding that
>the LDM
>would create those needed directories.  Unsure of what you meant, I went
>ahead and
>created those directories myself.  But I am still seeing lots of errors in
>the log file:



The LDM will create directories if you are using "FILE" from the LDM to
store data. But, once you PIPE data from the LDM to any other program,
the LDM has no control over what that program does with the data.
Thje decoders that I create do make the directories as needed-
but those from NCEP do not. So, create all the directories and log directories
you want decoders to write to.

As you discovered, teh GEMPAK GEMTBL directory where the stns, pack and other 
directories
needed by the decoders is under the "gempak/tables" directory under the $NAWIPS 
home.
The tables under $NAWIPS/tables are generally related to the operation of GUI 
programs.

Steve Chiswell
Unidata User SUpport


>
>Aug 01 12:22:07 cloudcover pqact[5990]: pipe_prodput: trying again
>Aug 01 12:22:07 cloudcover pqact[5990]: pbuf_flush (11) write: Broken pipe
>Aug 01 12:22:07 cloudcover pqact[5990]: pipe_dbufput:
>decoders/dcgrib2-ddata/gempak/logs/dcgrib.log-eGEMTBL=/us
>r/local/gempak/GEMPAK5.6/tables write error
>Aug 01 12:22:07 cloudcover pqact[5990]: pipe_prodput: trying again
>Aug 01 12:22:07 cloudcover pqact[5990]: pbuf_flush (11) write: Broken pipe
>Aug 01 12:22:07 cloudcover pqact[5990]: pipe_dbufput:
>decoders/dcgrib2-ddata/gempak/logs/dcgrib.log-eGEMTBL=/us
>r/local/gempak/GEMPAK5.6/tables write error
>Aug 01 12:22:07 cloudcover pqact[5990]: pipe_prodput: trying again
>Aug 01 12:22:07 cloudcover pqact[5990]: pbuf_flush (11) write: Broken pipe
>Aug 01 12:22:07 cloudcover pqact[5990]: pipe_dbufput:
>decoders/dcgrib2-ddata/gempak/logs/dcgrib.log-eGEMTBL=/us
>r/local/gempak/GEMPAK5.6/tables write error
>
>When I installed, I unpacked the binary tar file in
>/usr/local/gempak/GEMPAK5.6
>and then copied the decoders to the ~ldm/decoders directory as instructed in
>the
>README file.  I can't figure out if the write error is in the tables
>directory or the
>log directory?  I think the problem is with the install, but I don't know
>what it
>could be.  I followed the README instructions exactly.
>
>Thanks for your help.
>
>Wayne
>
>
>>
>> Wayne,
>>
>> GEMPAK only supports 8 bit color displays, You can run multiple X servers
>as
>> per the message from Mike Leuthold in the support archives for RH 7.1 if
>you want to
>> hot swap (ctl-alt-F7 & F8) between the two displays for different uses. I
>have verfied that
>> GEMPAK is successful under KDE. U. Arizona reports they use TWM as well.
>>
>> The GEMPAK decoders from NCEP (eg dcmetr, dcuair, etc) require that you
>create the data directory
>> (and log directory) they will be using. The pqact.conf actions that FILE
>data from
>> the LDM do create the data directory if it doesn't exist as do my decoders
>> such as dcgrib2, dcacars, dcncprof, dcnldn.
>>
>> Steve Chiswell
>> Unidata User SUpport
>>
>>
>>
>> >From: Wayne Bresky <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200107301904.f6UJ4m103007
>>
>> >Unidata Support wrote:
>> >
>> >> >From: Wayne Bresky <address@hidden>
>> >> >Organization: Cornell
>> >> >Keywords: 200107301341.f6UDfV121470 Linux X GEMPAK McIDAS
>> >>
>> >> Wayne,
>> >>
>> >> Steve Chiswell is currently hosting the GEMPAK training workshop here
>> >> in Boulder.  You may have to wait for his authoritative answer
>> >> on the gempak questions.
>> >>
>> >> >So you can only run Gempak with 8-bit color?  I was not aware of this.
>> >>
>> >> This is correct.
>> >>
>> >> >So what do you do if you want to run Gempak and McIDAS on the same
>> >> >machine?
>> >>
>> >> In Linux, you can run two X servers at one time and hot key between
>them.
>> >>
>> >> >I have encountered problems running McIDAS using KDE
>> >> >(no image window displayed), so I switched to Gnome for that user.
>> >>
>> >> Right.
>> >>
>> >> >But if I also want to run Gempak on the same machine I have to
>configure
>> >> >my display to use 8-bit color.  Now when I run McIDAS I get a message
>> >> >informing me that I should run with fewer colors.
>> >>
>> >> Right.
>> >>
>> >> >Gnome is, as you say,
>> >> >eating up all the available colors.  Is there any solution?
>> >>
>> >> The only thing I can offer you right now (until I can figure out the
>> >> reason that McIDAS fails under KDE) is the running of two X servers.
>> >>
>> >> Here is the note from a user telling us about how he worked around the
>> >> 8/24 bit color problems:
>> >>
>> >>   Date: Thu, 12 Jul 2001 15:52:12 -0700
>> >>   From: Mike Leuthold <address@hidden>
>> >>
>> >>   Chiz,
>> >>           I don't know if anyone has come up with this yet, but I've
>come up
>> >>   with a work around for the 'not enough colors' problem and am able to
>have
>> >>   a 24 bit display and a 8 bit display.  Redhat Linux supports 2
>separate X
>> >>   server processes.  I've set my default (:0) server to 24 bit and set
>the
>> >>   secondary to 8 bit (:1).  What I did, was run X :1 -depth 8, fire up
>a
>> >>   xterminal on that screen, and a window manager (twm).  Linux supports
>> >>   toggling between them via the ctrl-alt-F7 and F8 keys.  I run ntl -s
>140
>> >>   on the :1 screen and just toggle back and forth.  It works well. You
>need
>> >>   quite a bit of memory though (I'm running 512MB) but that is no big
>deal
>> >>   on a PC.  The hardware is a 1.33GHz Athlon and a Geforce2 video card.
>> >>   This Athlon is incredibly fast running garp, by the way.  Steve
>Mullen and
>> >>   I plan on getting all Linux machines to replace our xterminals in the
>near
>> >>   future.
>> >>
>> >> So, you would run McIDAS in the 24-bit server and GEMPAK in the 8-bit
>> >> server.
>> >>
>> >> >Thanks for your help.
>> >>
>> >> I hope that this gets you going.  Again, Chiz will be totally occupied
>> >> by the workshop until Thursday.
>> >>
>> >> Tom
>> >>
>****************************************************************************
>> >> Unidata User Support                                    UCAR Unidata
>Program
>> >> (303)497-8644                                                  P.O. Box
>3000
>> >> address@hidden                                   Boulder, CO
>80307
>>
>>> -------------------------------------------------------------------------
>---
>> >> Unidata WWW Service                        http://www.unidata.ucar.edu/
>> >>
>****************************************************************************
>> >
>> >Thanks.  I can look into that.
>> >
>> >I am comparing data from two machines at this point.  One running RH6.2
>the ot
>> > her
>> >RH7.1.
>> >The RH7.1 machine is the one I am currently working on.  I did the binary
>inst
>> > all
>> >for gempak
>> >and the program is running, but I seem to be having a problem decoding
>the dat
>> > a.
>> >
>> >Do you know what would cause the following:
>> >
>> >Jul 30 18:38:47 cloudcover pqact[1005]: pipe_dbufput:
>>
>>decoders/dcgrib2-ddata/gempak/logs/dcgrib.log-eGEMTBL=/usr/local/gempak/GEM
>PAK
>> > 5.6/tables
>> >write error
>> >
>> >Also, I am only getting data in 3 gempak (LDM) subdirectories on the
>RH7.1
>> >machine
>> >
>> >drwxr-xr-x    3 ldm      Unidata      4096 Jul 27 17:47 nport
>> >drwxrwxr-x   16 ldm      Unidata      4096 Jul 29 14:47 nwx
>> >drwxr-xr-x    2 ldm      Unidata      4096 Jul 30 14:42 profiler
>> >
>> >
>> >whereas on the RH6.2 machine I see the following directories:
>> >
>> >drwxrwxrwx    2 ldm      unidata      4096 Jan 30  2001 acars/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jul 30 13:39 acft/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jul 30 13:30 airm/
>> >drwxrwxrwx    4 ldm      unidata      4096 Mar  1 10:04 images/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jul 30 13:15 isig/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jul 30 04:33 logs/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jan 26  2001 meta/
>> >drwxrwxrwx    4 ldm      unidata     12288 Jul 30 14:26 model/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jul 30 13:15 mos/
>> >drwxrwxrwx    4 ldm      unidata      4096 Feb  1 14:09 nexrad/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jan 26  2001 nldn/
>> >drwxrwxrwx    3 ldm      unidata      4096 Feb 20 14:31 nport/
>> >drwxrwxrwx   16 ldm      unidata      4096 Feb 28 12:35 nwx/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jul 30 14:31 profiler/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jul 29 21:15 profiler_bufr/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jan 31  2001 redbook/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jul 29 21:15 scd/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jul 30 13:15 ship/
>> >drwxrwxrwx    9 ldm      unidata      4096 Jan 30  2001 storm/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jul 29 21:15 surface/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jul 29 19:15 syn/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jul 29 21:15 upperair/
>> >drwxrwxrwx    2 ldm      unidata      4096 Jan 30  2001 watches/
>> >
>> >The pqact.conf files are essentially identical.  Did I screw up the
>binary
>> >install?
>> >
>> >Also, I am still getting the syslogd.pid error even after a reboot.
>> >
>> >Wayne
>> >
>>
>>
>****************************************************************************
><
>> Unidata User Support                                    UCAR Unidata
>> (303)497-8644                                                  P.O. Box
>> address@hidden                                   Boulder, CO
>> --------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/
><
>>
>****************************************************************************
><
>