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

Re: 20041013: 20041012: 20041012: ACARS



Chiz,

I am revisiting this problem as we are still not getting the 
ACARS data written to the GEMPAK format.  At least now I have
a log file for acars and it looks like this

Oct 19 18:51:06 dcacars[1655]: Could not open gempak/acars/.tmp_netcdf.r0p5bw
^@Oct 19 18:51:06 dcacars[1655]: could not decode data -1
^@Oct 19 18:51:06 dcacars[1661]: Could not open gempak/acars/.tmp_netcdf.LDH56z
^@Oct 19 18:51:06 dcacars[1661]: could not decode data -1
^@Oct 19 18:51:06 dcacars[1667]: Could not open gempak/acars/.tmp_netcdf.v2WiJA
^@Oct 19 18:51:06 dcacars[1667]: could not decode data -1
^@Oct 19 18:51:06 dcacars[1673]: Could not open gempak/acars/.tmp_netcdf.p8dsYD
^@Oct 19 18:51:06 dcacars[1673]: could not decode data -1
^@Oct 19 18:51:06 dcacars[1679]: Could not open gempak/acars/.tmp_netcdf.fQXK0C
^@Oct 19 18:51:06 dcacars[1679]: could not decode data -1
^@Oct 19 18:51:06 dcacars[1685]: Could not open gempak/acars/.tmp_netcdf.PF52lG
^@Oct 19 18:51:06 dcacars[1685]: could not decode data -1

I am not sure why I get these messages.  The gempak acars directory has the
same permissions as all the other data directories.  I don't know why the
ldm can't write to it.  

Donna Tucker                       1475 Jayhawk Blvd.
Associate Professor                213 Lindley Hall 
address@hidden                     Department of Geography
(785) 864-4738                     University of Kansas                 
(785) 864-5378 (fax)               Lawrence, KS  66045-7613                    


> 
> 
> Donna,
> 
> Great. You can comment out that line.
> Typically, I suggest that users copy over the GEMPAK decoders
> into an ~ldm/decoders directory, but its not critical. Primarily,
> it just makes it easier for me to provide the pqact.gempak_decoders
> templates so that decoders are relative to the running LDM directory as
> decoders/dc*. That way, you wouldn't have to edit the patterns
> I provide with full paths to the decoders. 
> 
> The util directory under ldm is where we put scripts etc. that
> the LDM uses. Again, not critical. 
> 
> I'll change the dcgunzip script to avoid that error.
> 
> Steve Chiswell
> 
> 
> 
> 
> 
> >From: address@hidden
> >Organization: UCAR/Unidata
> >Keywords: 200410131515.i9DFF7UE023964
> 
> >Chiz,
> >
> >I think I have found the problem but I do not know what to do about
> >it.  The dcgunzip script has the line
> > 
> >setenv PATH ~ldm/util:~ldm/decoders
> >
> >My system does not have a user ldm.  Yes, I know we are supposed to
> >set it up that way but for unknown reasons my system administrator
> >has not done this.  We have a user weasw and ldm, gempak, mcidas...
> >all run under that user.  The user weasw does have a directory
> >for ldm files but there is no directory util in it nor is util listed
> >in $GEMPAKHOME.  Thus, I am not sure where this is supposed to point.  
> >I assume decoders can point to /lsw/wea/gempak/bin/linux since all
> >our gempak decoders are in that directory. 
> >
> >Donna Tucker                    1475 Jayhawk Blvd.
> >Associate Professor             213 Lindley Hall 
> >address@hidden                     Department of Geography
> >(785) 864-4738                          University of Kansas                
> >  
> >(785) 864-5378 (fax)               Lawrence, KS  66045-7613                  
> > 
> >  
> > 
> >
> >> 
> >> Donna,
> >> 
> >> Well......
> >> 
> >> I recall you saying that you are sucessfully storing the NETCDF format data
> >> currently correct? Without stats, I can't tell that you are getting the 
> >> data
> > .
> >> 
> >> The next step would be to verify that dcgunzip is logging to the ldmd.log 
> >> fi
> > le.
> >> The script has a line:
> >>    echo "$argv" | logger -t "$0 [$$]" -p local0.notice
> >> 
> >> The log output you provided doesn't show this log output.
> >> The above command should write the program invoked such as:
> >> Oct 12 14:52:11 shemp decoders/dcgunzip [75960]: decoders/dcacars 
> >>            -e GEMTBL=/home/gempak/NAWIPS/gempak/tables 
> >>            -l data/gempak/logs/dcacars.log data/gempak/acars/YYYYMMDDHH_ac
> > ars.gem
> >> 
> >> in the above where I have "shemp" you should see "chinook" and the line
> >> as appropriate to your pqact.conf. Perhaps a  "grep dcgunzip 
> >> ~ldm/logs/ldmd.
> > log"
> >> would help sift through the logs. If the output isn't there, then perhaps
> >> you need to add the path for logger.
> >> 
> >> If you only find your pqact dbufput/write error messages, then try running
> >> the logger command by hand such as
> >> echo "Starting Up" | logger -t "test logger" -p local0.notice
> >> 
> >> 
> >> If logger suceeds, you should have output to ldmd.log.
> >> 
> >> Have you tried cat'ing one of your NetCDF files to dcacars? I seem
> >> to recall you saying that yuou did that.
> >> 
> >> Steve CHiswell
> >> Unidata User Support
> >> 
> >> 
> >>  
> >> 
> >> >From: address@hidden
> >> >Organization: UCAR/Unidata
> >> >Keywords: 200410121824.i9CIO1UE019761
> >> 
> >> >Chiz,
> >> >
> >> >Yes, I copied dcgunzip to /lsw/wea/gempak/bin/linux  It gave me
> >> >one less directory to keep track of.  As you can see it would use
> >> >the gunzip in the directory that is hard coded in dcgunzip
> >> >
> >> >[ chinook-weasw ] pwd
> >> >/lsw/wea/gempak/bin/linux
> >> >[ chinook-weasw ] which gunzip
> >> >/usr/bin/gunzip
> >> >
> >> >gempak/acars and gempak/profiler have the same permissions.  
> >> >The log files would be written to the same directory.  
> >> >
> >> >This is a puzzle.
> >> >
> >> >Donna Tucker                         1475 Jayhawk Blvd.
> >> >Associate Professor                  213 Lindley Hall 
> >> >address@hidden                     Department of Geography
> >> >(785) 864-4738                       University of Kansas                
> >> >  
> >> >(785) 864-5378 (fax)               Lawrence, KS  66045-7613               
> >> > 
> >    
> >> >  
> >> >
> >> >
> >> >
> >> >> 
> >> >> Donna,
> >> >> 
> >> >> The dcgunzip script is in $NAWIPS/bin/scripts and not
> >> >> the /lsw/wea/gempak/bin/linux/ directory, unless you copied it there.
> >> >> 
> >> >> Since the dcacars.log file isn't being created, it is likely that
> >> >> either the dcgunzip script isn't found, or the gunzip program
> >> >> that the script uses isn't being found in the LDM's path
> >> >> (if that is the case, just hard code the path in the script).
> >> >> 
> >> >> Otherwise, you shouldn't have to....but just in case permissions are
> >> >> not as expected, make sure the output directory exists and is writable.
> >> >> I note that I configure the decoders to write to data/gempak/acars,
> >> >> whereas you are writing to gempak/acars , but I'm assuming that is 
> >> >> correc
> > t
> >> >> for your system since the profiler data is being decoded.
> >> >> 
> >> >> Steve Chiswell
> >> >> Unidata User Support
> >> >> 
> >> >> >From: address@hidden
> >> >> >Organization: UCAR/Unidata
> >> >> >Keywords: 200410121553.i9CFrUUE002069
> >> >> 
> >> >> >Still trying to get the mysterious ACARS data into gempak format.  The
> >> >> >pqact.log file gives
> >> >> >
> >> >> >Oct 12 15:22:24 pqact[29071]: pbuf_flush (17) write: Broken pipe
> >> >> >^@Oct 12 15:22:24 pqact[29071]: pipe_dbufput: 
> >> >> >-close/lsw/wea/gempak/bin/
> > lin
> >> > ux/
> >> >> > dcgunzip/lsw/wea/gempak/bin/linux/dcacars-b30-eGEMTBL=/lsw/wea/gempak/g
> > emp
> >> > ak/
> >> >> > tables-l/var/wea/gempak/dcacars.loggempak/acars/YYYYMMDDHH_acars.gem 
> >> >> > wr
> > ite
> >> >  er
> >> >> > ror
> >> >> >^@Oct 12 15:22:24 pqact[29071]: child 29155 exited with status 1
> >> >> >^@Oct 12 15:22:24 pqact[29071]: child 29156 exited with status 1
> >> >> >
> >> >> >Seems like it has trouble writing.  It does not write a dcacars.log 
> >> >> >file
> > .
> >> >> >I am not sure why this is.  Compare
> >> >> >
> >> >> >SL2    ^FSL\.NetCDF\.NOAAnet\.windprofiler\.(06min)\.
> >> >> >        PIPE    -close
> >> >> >                /lsw/wea/gempak/bin/linux/dcncprof
> >> >> >                -e GEMTBL=/lsw/wea/gempak/gempak/tables
> >> >> >                -l /var/wea/gempak/dcncprof.log
> >> >> >                gempak/profiler/YYYYMMDD00_6min.gem
> >> >> >
> >> >> >with  
> >> >> >
> >> >> >PCWS    ^FSL\.CompressedNetCDF\.MADIS\.acars\.
> >> >> >        PIPE    -close
> >> >> >        /lsw/wea/gempak/bin/linux/dcgunzip
> >> >> >        /lsw/wea/gempak/bin/linux/dcacars -b 30
> >> >> >        -e GEMTBL=/lsw/wea/gempak/gempak/tables
> >> >> >        -l /var/wea/gempak/dcacars.log
> >> >> >        gempak/acars/YYYYMMDDHH_acars.gem
> >> >> >
> >> >> >The profiler data come in fine and a log file gets written.  The
> >> >> >acars data are not written and neither is a log file. 
> >> >> >
> >> >> >Donna Tucker                      1475 Jayhawk Blvd.
> >> >> >Associate Professor               213 Lindley Hall 
> >> >> >address@hidden                     Department of Geography
> >> >> >(785) 864-4738                            University of Kansas         
> >> >> >       
> >> >> >  
> >> >> >(785) 864-5378 (fax)               Lawrence, KS  66045-7613            
> >> >> > 
> >    
> >> >    
> >> >> >  
> >> >> > 
> >> >> >
> >> >> --
> >> >> *************************************************************************
> > ***
> >> >  <
> >> >> Unidata User Support                                    UCAR Unidata 
> >> >> Prog
> > ram
> >> >  <
> >> >> (303)497-8643                                                  P.O. Box 
> >> >> 3
> > 000
> >> >  <
> >> >> address@hidden                                   Boulder, CO 80
> > 307
> >> >  <
> >> >> -------------------------------------------------------------------------
> > ---
> >> >  <
> >> >> Unidata WWW Service              
> >> >> http://my.unidata.ucar.edu/content/suppo
> > rt 
> >> >  <
> >> >> -------------------------------------------------------------------------
> > ---
> >> >  <
> >> >> 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.
> >> >> 
> >> >
> >> --
> >> ****************************************************************************
> >  <
> >> Unidata User Support                                    UCAR Unidata 
> >> Program
> >  <
> >> (303)497-8643                                                  P.O. Box 
> >> 3000
> >  <
> >> address@hidden                                   Boulder, CO 80307
> >  <
> >> ----------------------------------------------------------------------------
> >  <
> >> Unidata WWW Service              
> >> http://my.unidata.ucar.edu/content/support 
> >  <
> >> ----------------------------------------------------------------------------
> >  <
> >> 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.
> >> 
> >
> --
> **************************************************************************** <
> Unidata User Support                                    UCAR Unidata Program <
> (303)497-8643                                                  P.O. Box 3000 <
> address@hidden                                   Boulder, CO 80307 <
> ---------------------------------------------------------------------------- <
> Unidata WWW Service              http://my.unidata.ucar.edu/content/support  <
> ---------------------------------------------------------------------------- <
> 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.
> 


pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy