Re: 20040126:gribtonc and valtime_offset

• To: "Hanson, Kurt" <khanson@xxxxxxx>
• Subject: Re: 20040126:gribtonc and valtime_offset
• From: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx>
• Date: Mon, 26 Jan 2004 14:19:48 -0700 (MST)

Kurt,

I understand you point of view. If/when I get a chance I'll implement
those mods.  Since I usually create most of the cdls for the users the
idea of entering the valtime_offset info into the cdl rest on me.
Also the offsets usually don't change very much, not much maintenance There
are some netcdf clients that expect the data in the monotonoc form so it's
important.

gribtocdl makes many mistakes, its purpose is to be a starting point and
then the user needs to fine tune the cdl.

For the avn 1 degree the var

valtime_offset = 0, 6, 12, 18 ;

with dimension

valtime_offset = 4

should of worked.

I'll attach a avn one degree cdl.


Robb...


On Mon, 26 Jan 2004, Unidata Support wrote:

------- Forwarded Message

>To: "'support-decoders@xxxxxxxxxxxxxxxx'" <support-decoders@xxxxxxxxxxxxxxxx>
>From: "Hanson, Kurt" <khanson@xxxxxxx>
>Subject: gribtonc and valtime_offset
>Organization: UCAR/Unidata
>Keywords: 200401261726.i0QHQlp2002589

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_000_01C3E431.8ED5C2D0
Content-Type: multipart/alternative;
        boundary="----_=_NextPart_001_01C3E431.8ED5C2D0"


------_=_NextPart_001_01C3E431.8ED5C2D0
Content-Type: text/plain;
        charset="windows-1252"

Hello --

Like my previous email, the following concerns the gribtonc utility, as
contained in version 3.0.1 of the decoders package.

I stumbled upon the support email:
http://www.unidata.ucar.edu/projects/coohl/mhonarc/MailArchives/decoders/msg
00544.html

only after struggling to use gribtonc to convert an "AVN" grib to NetCDF.
The grib file was a concatenation of all forecast hours for a particular run
of the 1 degree, global GFS model. I think my problems in generating a valid
NetCDF file were limited to the valtime_offset stumbling block referenced in
the previous support email. It provides the tip that one should manually add
data for the valtime_offset variable to the CDL file obtained by a run of
gribtocdl. In my usage, I gave gribtonc a CDL file that did not define any
values for valtime_offset, and it created output that did not have good data
for this variable either.

So I tried to "fix" gribtonc with regards to the valtime_offset issue. I
have fix in quotes since I changed it to meet my goals, but I'm not sure if
my solution is a universal one for all uses of gribtonc. Nonetheless, here's
my thinking...

In psuedocode, the current version of getrec(...) in recs.c does the
following (amongst other things):

---
if (the output file has no records)
    initialize and write out the reftime and valtime variables based on the
values of valtime_offset found in the CDL file

if (we found the requested record)
    return its index

// else write a new record
Append an element to the reftime array equal to the reftime function arg
Append an element to the valtime array equal to the valtime function arg
Compute and append a new element of the datetime array (if it exists) based
on the htp function arg

return the new record index
---

Note that it does not append a new element to the valtime_offset variable
when adding a new record -- after all, it assumes data already exists for
this variable.

My thinking is that whenever we need to create a new record in getrec(...),
we can just use the htp->valoffset value we get in the htp function arg. A
new version of getrec is attached; when it is used to overwrite the existing
getrec(...) in recs.c, "make gribtonc" compiles successfully and the
resulting executable seems to do as I wanted it to.

My implementation no longer initializes the output variables when it finds
no records in the output file. Instead, these variables are written on an
as-needed basis.

I suspect that the most useful version of gribtonc might handle BOTH cases
-- when valtime_offset has data in the input CDL, and when it does not. What
do you think?

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/
==============================================================================