NOTE: The decoders mailing list is no longer active. The list archives are made available for historical reasons.
On Wed, 20 Oct 2004, Dan Swank wrote:
I copied the narr.cdl file from the FTP and tried: gribtonc -v -l ./log -e ./error ./narr.cdl narr-b_221_20010101_0000_000.nc < narr-b_221_20010101_0000_000.grb
here's the process # creates cdl file narr.cdl % gribtocdl -v narr-b_221_20010101_0000_000.grb > narr.cdl # creates netcdf file narr.nc in verbose mode, logging to screen % gribtonc -vl - narr.cdl narr.nc < narr-b_221_20010101_0000_000.grb
Result Segmentation fault
explained below, set UDUNITS_PATH
and Oct 20 19:31:05 gribtonc[32594]: Starting Up in the ./log file. Any idea whats going on? It is likely gribtonc (or more likely one of its dependancies) is not installed correctly on our system (RedHat 7.3) Also, what did you use to create this CDL file? The data in cdl seems like a translation of the information in the grib PDS, reworked into a format that ncgen can understand. Any way i can get anymore debug information regarding this? Only hunch is that it is not happy with the udunits package -> /usr/local/udunits-1.11.7/udunits-1.11.7/bin/udunits udunits(3): Couldn't open units database "/upc/udunits/etc/udunits.dat":
ahh, that's the problem. udunits can't find udunits.dat either place udunits.dat in dir /upc/udunits/etc/ or set environment var % setenv UDUNITS_PATH /your/udunits/path/udunits.dat replace /your/udunits/path/ with appropriate path robb...
No such file or directory Segmentation fault But, while building the unidata decoders package it only seemed to want the .dat .a and .h files within these packages. Would this be the source of the problems? -Dan Robb Kambic wrote: >Thanks russ for the clarification. i was assuming you were familar with >the decoders process. if i can answer any more questions let me know. i'll >try to be more descriptive. > >robb... > > >On Tue, 19 Oct 2004, Dan Swank wrote: > > > >>Russ >> >>Actually, i was, at first, trying >>GRIB -( gribtocdl )-> CDL -( gribtonc )-> NetCDF >>Which i now understand is completely wrong, thanks for the help. >>As you have noticed, we are completely unfamiliar with these programs. >> >>Attempting it the correct way now, i'll let you know how it goes. >> >>-Dan >> >> >> >>Russ Rew wrote: >> >> >> >>>Robb, >>> >>> >>> >>> >>> >>>>i downloaded the file from the last message, created a cdl, and decoded >>>>the grb file. there might be something wrong with Dan's decoders build or >>>>it could be a platform issue. this was done on a solaris box 5.9 The >>>>narr.cdl file is attached and the files narr.cdl, narr.grb, and narr.nc are >>>>in the Unidata's ftp dir at >>>> >>>>ftp unidata.ucar.edu >>>> >>>>% cd pub/contrib >>>>% mget narr* >>>> >>>> >>>> >>>> >>>Thanks Robb. The file sizes are: >>> >>> -rw-rw-r-- 1 rkambic ustaff 3486764 Oct 19 13:32 narr.nc >>> -rw-rw-r-- 1 rkambic ustaff 8560 Oct 19 13:32 narr.cdl >>> -rw-rw-r-- 1 rkambic ustaff 1398914 Oct 19 13:32 narr.grb >>> >>>so the netCDF file is about 2.5 times as big as the GRIB file. >>> >>>I'm guessing the source of the problem may come from using >>> >>> GRIB -> (via gribtocdl) -> CDL -> (via ncgen) -> netCDF >>> >>>(Using gribtocdl to generate a very large CDL file and then using ncgen >>>to convert that into a netCDF file.) >>> >>>I think Robb used the following tools instead: >>> >>> GRIB -> (via gribtocdl) -> CDL >>> GRIB and CDL -> (via gribtonc) -> netCDF >>> >>>(Using gribtocdl to generate a small CDL file describing structure of >>>the desired netCDF file and then using gribtonc to convert the GRIB >>>data into the netCDF file.) >>> >>>--Russ >>> >>> >>> >>> >>-- >>Dan Swank <dan.swank@xxxxxxxx> >>NOMADS programmer >>STG, Incorporated - Government Contractor >>151 Patton Avenue, Room 514 >>Asheville, NC 28801 >>Phone: 828-271-4007 >> >> >> >> > >============================================================================== >Robb Kambic Unidata Program Center >Software Engineer III Univ. Corp for Atmospheric Research >rkambic@xxxxxxxxxxxxxxxx WWW: http://www.unidata.ucar.edu/ >============================================================================== > > -- Dan Swank <dan.swank@xxxxxxxx> NOMADS programmer STG, Incorporated - Government Contractor 151 Patton Avenue, Room 514 Asheville, NC 28801 Phone: 828-271-4007
============================================================================== Robb Kambic Unidata Program Center Software Engineer III Univ. Corp for Atmospheric Research rkambic@xxxxxxxxxxxxxxxx WWW: http://www.unidata.ucar.edu/ ==============================================================================
decoders archives: