[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 20041013: 20041012: 20041012: ACARS
- Subject: Re: 20041013: 20041012: 20041012: ACARS
- Date: Wed, 20 Oct 2004 14:08:09 -0500 (CDT)
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.
>