[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20041013: 20041012: 20041012: ACARS
- Subject: 20041013: 20041012: 20041012: ACARS
- Date: Wed, 13 Oct 2004 10:44:14 -0600
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.
>>
>
--
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.