NOTE: The decoders mailing list is no longer active. The list archives are made available for historical reasons.
Lori,
I made some changes to gribtocdl that might solve the problem that you
were having that created an extra record in the resulting netCDF file. The
new gribtocdl.c file is in the ftp decoders dir if you want to test it.
There will be a decoders release in a couple of weeks.
Robb...
Lori,
I received the grib file and created a cdl file for your isabel data.
The cdl from gribtocdl had to be modified a litte because it had
valtime offsets of 0 and 6 because the PRECIP var is actually a time
range and gribtocdl doesn't handle that well. ie
_From gribdump:
Time Range Indicator : Accumulation from P1 to P2
Time 1 (P1) : 0
Time 2 (P2) : 6
other vars were similar too:
Time Range Indicator : Reference Time + P1
Time 1 (P1) : 6
When gribtonc ran on the data, it only created one record for the 6 hr data.
The cdl is a attached.
Robb...
On Thu, 26 Feb 2004, Robb Kambic wrote:
On Thu, 26 Feb 2004, Unidata Support wrote:
>
> ------- Forwarded Message
>
> >To: support-decoders@xxxxxxxxxxxxxxxx
> >From: Lori Thompson <Lori.Thompson@xxxxxxxx>
> >Subject: valtime_offset problems
> >Organization: UCAR/Unidata
> >Keywords: 200402261855.i1QItjrV024503
>
> We recently upgraded to the decoders version 3.0.2. I am converting a
> dataset from grib to NetCDF. During the conversion, each snapshot file was
> concatenated using nccatm to produce a time series file. I seem to be
> running into problems with this newer version where additional points are
> added to the record dimension during gribtonc, creating additional
> 9actually doubling) blank frames in the time series. I have made several
> attempts to manipulate the CDL file so that the record dimension will only
> have 1 value per file but these efforts failed. Is there a new feature
> with the upgrade that is causing this, or am I doing something wrong?
Lori,
I am not quite sure that what your question is?
The valtime_offsets are extracted from the data files. The
offsets must be in the raw grib data you used to make the cdl. You could
use use the gribdump utility to check your grib input file. ie
% gribdump <rawgrib> | less
...
Time Range Indicator : Reference Time + Long P1
Time 1 (P1) : 0
Time 2 (P2) : 12
...
This would result in a valtime_offset of 12. You could edit the cdl file
in the data section. Removing some of the values for the
valtime_offset, only used the offsets in the data that you are decoding.
I don't know what the result would be if the variable valtime_offset was
removed from the data section. You would get some errors but not fatal
errors.
If none of the above ideas work, you might want to use the old version of
the decoder and modify the gribtocdl file section to look like lines
1882-1937 in the latest gribtocdl. I think that the actual changes might
be only a couple lines in that section. A simple recompile might solve
your problem.
Let me know your findings. If you are still having problems, send me your
cdl an a sample grib file.
Robb....
>
> Thanks,
> Lori
>
> --
> ----------------------------------------------------
> Lori A. Thompson
> Applications Programmer/RS Information Systems, Inc.
> Geophysical Fluid Dynamics Laboratory/NOAA
> Princeton University Forrestal Campus/Route 1
> PO Box 308
> Princeton, NJ 08542
> Phone: 609-452-6563
> Fax: 609-987-5063
> http://www.gfdl.noaa.gov/~lat
>
> --
> 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: