[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 20040123: Sample GFS 1x1 deg cdl
- Subject: Re: 20040123: Sample GFS 1x1 deg cdl
- Date: Fri, 23 Jan 2004 15:42:31 -0700 (MST)
> >To: decoders <address@hidden>
> >From: Jim Cowie <address@hidden>
> >Subject: Re: Sample GFS 1x1 deg cdl
> >Organization: NCAR/RAP
> >Keywords: 200401232035.i0NKZbp2012804 gribtonc CDL
>
> Robb Kambic wrote:
> >
> > Jim,
> >
> > Thanks for responding to the email. I'm curious about what time
> > averages/variables are you talking about? DOn't want to skip it in the new
> > gribtonc.
> >
>
> Robb,
>
> As I recall (and it's been a couple years now) there were two issues
> related to fields defined over a time range. The first was for fields
> that are averaged over a period. The stock gribtonc decoder creates a
> new time for these fields at the interval mid-point and stores them at
> that time. This tends to waste a lot of space in the file since there
> are few (if any) other fields valid at this new time. I modified it to
> store the field at the interval end time. This is also convenient for
> our software since we don't have to look for an intermediate time.
> However, this change causes a potential problem if both instantaneous
> and time averaged fields exist in the GRIB data since they will both
> get stored at the same time, overwriting each other. There are GRIB
> sets like this but fortunately not many, and for our purposes the grid
> we want is usually later in the GRIB file and hence overwrites the one
> we don't want.
Rorik,
The above explaination by Jim is the reason for the extra netCDF record in
the file. I actually found 5 variables in the Alaska 15 hour file that had
instantanous and average times. The variables don't cause an extra record
unless the data is actually requested by the cdl. Also, if grib product is
missing then the record isn't created either. This could be the reason
that some days the record is created and others not. By using gribdump
output:
Parameter : 212 (ulwrf)
Units : W/m2
Level Type : Surface
Reference Time : 2004/01/22:00:00
Time Unit : Hour
Time Range Indicator : Reference Time + P1
Time 1 (P1) : 15
Parameter : 212 (ulwrf)
Units : W/m2
Level Type : Top of Atmosphere
Reference Time : 2004/01/22:00:00
Time Unit : Hour
Time Range Indicator : Average from P1 to P2
Time 1 (P1) : 12
Time 2 (P2) : 15
I'm still looking at this problem and the following problem. Will keep
you informed.
Robb...
>
> The other issue is for fields defined over an accumulation interval.
> There are GRIB sets (EG; eta 212 grid) where you get the same field
> (eg; PRECIP) accumulated over different time periods but ending at the
> same time. In that case, multiple grids get the same netcdf name and
> are stored at the same time and grids get overwritten. To deal with
> this I added the accumulation interval to the netcdf (cdl) name to
> distinguish them.
>
> I'm not sure what the best solution to these problems is. Perhaps you
> add more information to a time-period variable name to distinguish it
> from an instantaneous grid, or perhaps you add a time index to the variable
> definition, as is done with levels. But I'm glad you asked about this
> 'cause this is an important thing to be handled in the new decoder.
>
> -jim
>
>
> --
> Jim Cowie
> NCAR/RAP
> address@hidden
> 303-497-2831
>
> 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
address@hidden WWW: http://www.unidata.ucar.edu/
===============================================================================