[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idvusers] Time in GRIB2 files from CFSR

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: [idvusers] Time in GRIB2 files from CFSR
  • Date: Mon, 15 Mar 2010 16:15:52 -0600 (MDT)
On Mon, 15 Mar 2010, Guilherme Chagas wrote:


Hi Robb,


I fixed the Time problem but I was comparing the results with wgrib2. It
seems that wgrib2 calculates the forecast time differently then our grib
library. Our library figures out the valid time that is the end of the
accumulation interval verses the wgrib2 that uses the start of the interval.


Since the accumulation interval is 1 month the difference should be no
bigger than 1 month... The way I see it, for the monthly average of
January 1979 instead of 1979010100 one would see 1979013123 (or
1979020100).



Guilherme,
I was interpreting the time ranges wrong for the forecast time. Since there are two ranges, the first has value 124 and second has value 6. The 
forecast time is calculated as the
reference time + forecast time + ( 124 * 6 ) which equals

 1979-02-01 00:00:00Z
 1979-03-01 00:00:00Z
 1979-04-01 00:00:00Z
 1979-05-01 00:00:00Z
 1979-06-01 00:00:00Z
 1979-07-01 00:00:00Z
 ...
These are the forecast times, the reference time is 1979010100. The definition of forecast time for accumulations is at the end of the interval, so if it's a month interval then the end would be the start of the next month. These calculations seem correct to me. 

Robb...


hours since 1979-01-01T00:00:00Z
time = 124, 856, 1540, 2280, 3004, 3744, ....
 1979-01-06 04:00:00Z
 1979-02-05 16:00:00Z
 1979-03-06 04:00:00Z
 1979-04-06 00:00:00Z
 ...

wgrib2:

1.1:0:d=1979010100
2.1:149612:d=1979020100

Does this make sense?


While it appears that there is a 1 month time-step between records the
first one starts at 124 hours, when it *should* start at 00Z
(1979010100). It does get the months right, but perhaps this
difference on the first record might wrongly increase the gaps between
each record, eventually leading to differences in the Time (month)
itself after several steps. Nevertheless the 124 hours at the first
record makes no sense since it's supposed to be a monthly average!

Do you believe that, despite the wrong initial time, the months will
correspond to what it's supposed to be, or that eventually it will
skip a month?

Best Regards,
___________________________
               Guilherme O. Chagas
                              address@hidden



===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================