[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 20040126:bug in gribtonc (fwd)
- Subject: RE: 20040126:bug in gribtonc (fwd)
- Date: Mon, 26 Jan 2004 10:46:04 -0700 (MST)
===============================================================================
Robb Kambic Unidata Program Center
Software Engineer III Univ. Corp for Atmospheric Research
address@hidden WWW: http://www.unidata.ucar.edu/
===============================================================================
---------- Forwarded message ----------
Date: Mon, 26 Jan 2004 12:39:11 -0500
From: "Hanson, Kurt" <address@hidden>
To: 'Robb Kambic' <address@hidden>
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:address@hidden]
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: "'address@hidden'"
<address@hidden>
> >From: "Hanson, Kurt" <address@hidden>
> >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
>
>
> ------_=_NextPart_001_01C3E422.880DC290
> Content-Type: text/html;
> charset="windows-1252"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dwindows-1252">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 5.5.2653.12">
> <TITLE>bug in gribtonc?</TITLE>
> </HEAD>
> <BODY>
>
> <P><FONT SIZE=3D2 FACE=3D"Arial">Hello --</FONT>
> </P>
>
> <P><FONT SIZE=3D2 FACE=3D"Arial">The following concerns the gribtonc =
> utility, as contained in version 3.0.1 of the decoders package.</FONT>
> </P>
>
> <P><FONT SIZE=3D2 FACE=3D"Arial">The getrec(...) function in recs.c =
> contains the following block:</FONT>
> <BR> <FONT SIZE=3D2 =
> FACE=3D"Courier New">/* get dimension and value of valtime_offset =
> */</FONT>
> <BR> <FONT SIZE=3D2 =
> FACE=3D"Courier New">dimvaloffsetsid =3D nuwg_getdim(ncid, =
> DIM_VALOFFSETS );</FONT>
> <BR> <FONT SIZE=3D2 =
> FACE=3D"Courier New">if (ncdiminq(ncid, dimvaloffsetsid, (char *)0, =
> &dimvaloffsets) =3D=3D -1) {</FONT>
> <BR> <FONT SIZE=3D2 =
> FACE=3D"Courier New"> uerror("%s: can't get =
> dimvaloffsets", nc->ncname);</FONT>
> <BR> <FONT SIZE=3D2 =
> FACE=3D"Courier New"> nerrs++;</FONT>
> <BR> <FONT SIZE=3D2 =
> FACE=3D"Courier New">}</FONT>
> </P>
>
> <P><FONT SIZE=3D2 FACE=3D"Arial">Also, nuwg.h contains these =
> definitions:</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New"> =
> DIM_VALOFFSETS, =
> /* number of offsets times =
> in this model */</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New"> =
> VAR_VALOFFSET, =
> /* valid time offset for =
> humans */</FONT>
> </P>
>
> <P><FONT SIZE=3D2 FACE=3D"Arial">And nuwg.c contains a function =
> nuwg_name(...) which returns "valtime_offset" for both =
> DIM_VALOFFSETS and VAR_VALOFFSET.</FONT>
> </P>
>
> <P><FONT SIZE=3D2 FACE=3D"Arial">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?</FONT></P>
>
> <P><FONT SIZE=3D2 FACE=3D"Arial">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:</FONT></P>
>
> <P><FONT SIZE=3D2 FACE=3D"Courier =
> New"> int =
> valoffsets_dim_count;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> int =
> valoffsets_dims[MAX_VAR_DIMS];</FONT>
> </P>
>
> <P><FONT SIZE=3D2 FACE=3D"Courier =
> New"> // Get the dimensions =
> of the VALOFFSET variable</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> int status =3D =
> ncvarinq(ncid,</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> &=
> nbsp; &=
> nbsp; nuwg_getvar(ncid, =
> VAR_VALOFFSET),</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> &=
> nbsp; &=
> nbsp; (char *)0,</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> &=
> nbsp; &=
> nbsp; (nc_type *)0,</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> &=
> nbsp; &=
> nbsp; &valoffsets_dim_count,</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> &=
> nbsp; &=
> nbsp; valoffsets_dims,</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> &=
> nbsp; &=
> nbsp; (int *)0);</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> if (status =3D=3D =
> -1)</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> {</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> =
> uerror("%s: can't get dimensions of variable '%s' (status: =
> %d)",</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> &=
> nbsp; nc->ncname,</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> &=
> nbsp; =
> nuwg_name(VAR_VALOFFSET),</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> &=
> nbsp; status);</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> =
> nerrs++;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> =
> return -1;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> }</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> else if =
> (valoffsets_dim_count > 1)</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> {</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> =
> uerror("%s: variable '%s' has %d dimensions but 1 is =
> expected",</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> &=
> nbsp; nc->ncname,</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> &=
> nbsp; =
> nuwg_name(VAR_VALOFFSET),</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> &=
> nbsp; valoffsets_dim_count);</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> =
> nerrs++;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> =
> return -1;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> }</FONT>
> </P>
>
> <P><FONT SIZE=3D2 FACE=3D"Courier =
> New"> // Get the size of the =
> VALOFFSET variable</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New"> dimvaloffsets =3D =
> valoffsets_dims[0];</FONT>
> </P>
>
> <P><FONT SIZE=3D2 FACE=3D"Arial">and, for completeness, DIM_VALOFFSETS =
> could be eliminated from nuwg.h and nuwg.c.</FONT>
> </P>
>
> <P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
>
> <P><FONT SIZE=3D2 FACE=3D"Arial">What do you think?</FONT>
> </P>
>
> <P><FONT SIZE=3D2 FACE=3D"Arial">Thanks --</FONT>
> </P>
>
> <P><FONT SIZE=3D2 FACE=3D"Arial">Kurt Hanson</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Arial">Scientific Software Engineer</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Arial">WSI Corporation</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Arial">400 Minuteman Rd.</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Arial">Andover, MA 01810</FONT>
> </P>
>
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C3E422.880DC290--
>
> 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.
> --
>
****************************************************************************
<
> Unidata User Support UCAR Unidata
> (303)497-8643 P.O. Box
> address@hidden Boulder, CO
>
----------------------------------------------------------------------------
<
> Unidata WWW Service
>
****************************************************************************
<
>
> ------- End of Forwarded Message
>
>
============================================================================
===
Robb Kambic Unidata Program Center
Software Engineer III Univ. Corp for Atmospheric
Research
address@hidden WWW: http://www.unidata.ucar.edu/
============================================================================
===