Re: 20041013: 20041012: 20041012: ACARS

Chiz,

Well, I guess I am making progress.  I now have a log file for acars
and it looks like this.

ct 13 16:52:16 dcacars[30331]: Could not open gempak/acars/.tmp_netcdf.JCuYVB
^@Oct 13 16:52:16 dcacars[30331]: could not decode data -1
^@Oct 13 16:52:16 dcacars[30337]: Could not open gempak/acars/.tmp_netcdf.xX3GVG
^@Oct 13 16:52:16 dcacars[30337]: could not decode data -1

I don't have this trouble running the decoder manually.  The directory
gempak/acars has the same permissions as all the other directories the
ldm writes to.  I get nothing in the ldmd.log file on this.  

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.
>