NOTE: The decoders mailing list is no longer active. The list archives are made available for historical reasons.
On Thu, 8 Jul 2004, Unidata Support wrote:
------- Forwarded Message >To: "Unidata Support (support@xxxxxxxxxxxxxxxx)" <support@xxxxxxxxxxxxxxxx> >cc: David Fitzgerald <David.Fitzgerald@xxxxxxxxxxxxxxxx> >From: David Fitzgerald <David.Fitzgerald@xxxxxxxxxxxxxxxx> >Subject: problem testing decoders package >Organization: Millersville University of Pennsylvania >Keywords: 200407081621.i68GLDaW022102 netCDF decoders Hi, I downloaded the newest decoders package. Configuration and compiling went fine, but and I am getting "NOT OK" messages when I run 'make test'. I already installed the newest versions of netcdf, udunits and netcdf-perl , and I set the CUSTOMIZE file to look at the new include files and libraries. The output for the make test gives: making `test' in directory /home/ldm/decoders-3.0.3/src/gribtonc make[1]: Entering directory `/home/ldm/decoders-3.0.3/src/gribtonc' *** gribdump -b ... \c OK *** gribdump -v ... \c OK *** gribdump -q ... \c OK make[1]: Leaving directory `/home/ldm/decoders-3.0.3/src/gribtonc' returning to directory /home/ldm/decoders-3.0.3/src perl test.pl perl Decoders tests takes > 30 seconds in batch mode ascii tested ...... OK ldmConnect tested . OK metar tested ...... NOT OK syn tested ........ NOT OK buoy tested ....... NOT OK upperair tested ... NOT OK The logfiles for each of the failed test all have this message: yyyymm must be 6 in length: Inappropriate ioctl for device Could there be a problem with the input testdata?
David,
I working on a new release and put out stuff a little to soon. There is a
problem with the test.pl script because the decoders require real time
data. Also the pqact entries need to include the centry ie
(2:yy) -> (2:yyyy)
There a newer release in the ftp dir now decoders-3.0.4.tar.Z that will
solve the problems your seeing.
robb...
Here's a preliminary announcement:
I'm pleased to announce the release of Decoders 3.0.?.
This release involved rewritting all the perl decoders so the date checking is
more robust. The wrong date problem is the most prominent error in all the text
type bulletins. The dates are now checked against the current time and reports
with future dates and dates older than 24 hours are not decoded. The
conseqence of the new code is that decoding data older than 24 hours now
doesn't work. The next release will have a flag to bypass the robust date
checking. Also, the output netCDF file now include the century as well as the
decade, so the pqact entries need to be changed to include century,
DDS|IDS ^S(A....|P....|XUS8.) .... ([0-3][0-9])
PIPE /local/ldm/decoders/metar2nc
etc/metar.cdl
data/pub/decoded/netcdf/surface
(\2:yyyy)(\2:mm)
(\2:yy) -> (\2:yyyy) for the old entries. This change needs to be done on all
the perl decoders.
There are new decoders that bust bulletins apart and write the reports under
the station name under a day named directory. ie
# All aviation reports including metar tests, broken/written to stn files
DDS|IDS ^S(A....|P....|XUS8.) .... ([0-3][0-9])
PIPE /local/ldm/decoders/metarWriter
data/pub/raw/metar
(\2:yyyy)(\2:mm)
#
The feedtype and pattern will be the same as the *2nc type decoders.
There are decoders for the METAR, synoptic, upperair, buoy, and zone reports.
# zone reports, broken/written to zone files
DDS|IDS ^FOUS5. .... ([0-3][0-9])
PIPE /local/ldm/decoders/zoneWriter
data/pub/raw/zone
(\1:yyyy)(\1:mm)
Make sure that the first line in all perl decoders match the perl install point
on your system.
There has been bug fixes to the gribtonc code:
- memory error when more than 32 forecast times
- gribtocdl creating a cdl that produces an extra record in the netCDF file
- more robust checking for parameter suffixes.
As always, if there are any question send them to support@xxxxxxxxxxxxxxxx
Thanks,
Robb...
Also, I had to change the location for my perl binary in the *2nc, *Writer scripts and the test.pl script but I can't see how that would be a problem as the netcdf and netcdf-perl installation seemed to go ok. Any ideas? Thanks! Dave ********************************************* David Fitzgerald Distributed System Specialist II Millersville University Millersville PA 17551 Phone: 717-871-2394 Fax: 717-871-4725 E-mail: david.fitzgerald@xxxxxxxxxxxxxxxx <mailto:david.fitzgerald@xxxxxxxxxxxxxxxx> >From David.Fitzgerald@xxxxxxxxxxxxxxxx Thu Jul 8 10:24:33 2004 Oops forgot to tell you. I am running these on RedHat Linux 9.0 Kernel 2.4.20-31.9smp, and compiling with gcc. Dave -- NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publically 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. ------- End of Forwarded Message
============================================================================== Robb Kambic Unidata Program Center Software Engineer III Univ. Corp for Atmospheric Research rkambic@xxxxxxxxxxxxxxxx WWW: http://www.unidata.ucar.edu/ ==============================================================================
decoders archives: