NOTE: The decoders mailing list is no longer active. The list archives are made available for historical reasons.
============================================================================== Robb Kambic Unidata Program Center Software Engineer III Univ. Corp for Atmospheric Research rkambic@xxxxxxxxxxxxxxxx WWW: http://www.unidata.ucar.edu/ ============================================================================== ---------- Forwarded message ---------- Date: Mon, 26 Jan 2004 12:39:11 -0500 From: "Hanson, Kurt" <khanson@xxxxxxx> To: 'Robb Kambic' <rkambic@xxxxxxxxxxxxxxxx> Subject: RE: 20040126:bug in gribtonc Hi Robb -- Re: the need for monotonically increasing: a ha! It does seem unfortunate to have both a valtime_offset dimension and variable, but apparently necessary. I realize my latest email "gribtonc and valtime_offset" crossed in the mail with the response you've given here; your response applies to both. Kurt -----Original Message----- From: Robb Kambic [mailto:rkambic@xxxxxxxxxxxxxxxxxxxxxxxx] Sent: Monday, January 26, 2004 12:25 PM To: Hanson, Kurt Subject: Re: 20040126:bug in gribtonc On Mon, 26 Jan 2004, Unidata Support wrote:
------- Forwarded Message >To: "'support-decoders@xxxxxxxxxxxxxxxx'"
<support-decoders@xxxxxxxxxxxxxxxx>
>From: "Hanson, Kurt" <khanson@xxxxxxx>
>Subject: bug in gribtonc?
>Organization: UCAR/Unidata
>Keywords: 200401261539.i0QFdEp2018354
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C3E422.880DC290
Content-Type: text/plain;
charset="windows-1252"
Hello --
The following concerns the gribtonc utility, as contained in version 3.0.1
of the decoders package.
The getrec(...) function in recs.c contains the following block:
/* get dimension and value of valtime_offset */
dimvaloffsetsid = nuwg_getdim(ncid, DIM_VALOFFSETS );
if (ncdiminq(ncid, dimvaloffsetsid, (char *)0, &dimvaloffsets) =
-1) {
uerror("%s: can't get dimvaloffsets", nc->ncname);
nerrs++;
}
Also, nuwg.h contains these definitions:
DIM_VALOFFSETS, /* number of offsets times in this model */
VAR_VALOFFSET, /* valid time offset for humans */
And nuwg.c contains a function nuwg_name(...) which returns
"valtime_offset"
for both DIM_VALOFFSETS and VAR_VALOFFSET. What's surprising to me is that there is code for considering the notion
of
"valid time offsets" as a dimension and also code for considering it a variable. Is this appropriate? In my experience, I've seen it only as a variable, but my experience is far from comprehensive! If it does appear
as
a dimension in certain contexts, could you provide an example?
Kurt,
The problem is that I never really had a chance to make an official
decoders release that explains your concerns. Everything you mention has
been done to make the data monotonically increasing in the netCDF file. To
make that happen, I had to enter the valtime_offsets into the cdl so
gribtonc would know where to enter the data in the file. For the eta
model, the
valtime_offset = 6, 12, 18, 24, 30, 36, 42, 48, 54, 60 ;
In the old gribtonc/cdls the data was packed into the file as it appeared
on the datastream, many times the 24 hr data came in before the 12 hr data
so that's the order it was in the file. Now, the code looks for the
valtime_offset to figure out where to place the data. I'm attaching the
eta.cdl as an working example. Actually it's been used at Unidata for the
last couple of months. Also, you might note the inclusion of a new
variable called:
char forecasttime(record, time_len) ; // derived from valtime
forecasttime:long_name = "forecast date and time" ;
// units YYYY-MM-DD hh:mm:ssZ (ISO 8601)
I'm planning on making a decoders release with the new cdls to match the
new code very soon, hopefully this week.
Robb...
If it is a bug, and should always be considered a variable, it seems the
following could replace the block quoted above in recs.c:
int valoffsets_dim_count;
int valoffsets_dims[MAX_VAR_DIMS];
// Get the dimensions of the VALOFFSET variable
int status = ncvarinq(ncid,
nuwg_getvar(ncid, VAR_VALOFFSET),
(char *)0,
(nc_type *)0,
&valoffsets_dim_count,
valoffsets_dims,
(int *)0);
if (status == -1)
{
uerror("%s: can't get dimensions of variable '%s' (status:
%d)",
nc->ncname,
nuwg_name(VAR_VALOFFSET),
status);
nerrs++;
return -1;
}
else if (valoffsets_dim_count > 1)
{
uerror("%s: variable '%s' has %d dimensions but 1 is
expected",
nc->ncname,
nuwg_name(VAR_VALOFFSET),
valoffsets_dim_count);
nerrs++;
return -1;
}
// Get the size of the VALOFFSET variable
dimvaloffsets = valoffsets_dims[0];
and, for completeness, DIM_VALOFFSETS could be eliminated from nuwg.h and
nuwg.c.
However, if whether the valid time offsets is a dimension or variable
depends on context, then it seems we'd need code to handle both
possibilities.
What do you think?
Thanks --
Kurt Hanson
Scientific Software Engineer
WSI Corporation
400 Minuteman Rd.
Andover, MA 01810
=========================================================================== == Robb Kambic Unidata Program Center Software Engineer III Univ. Corp for Atmospheric Research rkambic@xxxxxxxxxxxxxxxx WWW: http://www.unidata.ucar.edu/ =========================================================================== ==
decoders archives: