[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20000119: imgi2gm.f
- Subject: 20000119: imgi2gm.f
- Date: Wed, 19 Jan 2000 18:37:04 -0700
Dave,
I'm pulling all the GINI data off your dish...and have the NESDIS
interface control document...but neither tell me definitively what next year
will look like.
The reason I took the "and. le 100" out of the if branch was to
cover either possibility- as to years since 1900 and year of
a given century.
The reason I mentioned the grib protocol to year =100 of century=20
is that the GINI header is virtually identical to the grib block.
Steve Chiswell
Unidata User Support
On Wed, 19 Jan 2000, David Himes wrote:
> According to Steve Chiswell:
> >
> > Steve,
> >
> > As I read the NESDIS interface control document for the GINI product
> > data block (PDB), Octet 9 is Year of century. The way grib handles year 2000
> > is to say this is the 100th year of the 20th century. Then 2001 will
> > be year 1 of the 21st century.
> >
> > If the GINI header uses years since 1900, then your solution will work.
> > However, if the value next year is reset from 100 to 1, then it will fail
> > again.
>
> We typically don't mess around with the GINI data here, but we were
> responding to a bug from some NWS field office that was using GINI in
> GARP. GARP was incorrectly labeling the images with a year of 2100.
>
> He sent us a few images and we found that iyear was being set to 100
> for these images (the actual times for the images were ~ 1/11/2000
> 18z). We don't have any GINI documentation and jumped to the
> conclusion that GINI was using that field as years since 1900 (like the
> way the Unix tm structure is represented). Thus the patch that Steve
> Drakes sent to you.
>
> Do you have additional year 2000 GINI data you can do some testing
> on? We'd like to fix it correctly.
>
>
> > My assumption was that the conditional test would be:
> > if( iyear .gt. 70) then
> > iyear = 1900 + iyear
> > else
> > iyear = 2000 + iyear
> > endif
> >
> > The GINI PDB doesn't include a "century" octet, so I don't know
> > how they will represent 2001. The McIDAS formulation for imar2gm.f
> > uses CCC as years since 1900, but I don't know if GINI will do this or not.
> >
> > I think that for the present time, if we use the above, then we are covered
> > either way.
>
> If your assumptions are right, then we need to change the logic to
> be something like:
>
> if( iyear .gt. 70 .and. iyear .le. 100 ) then
> ^^^^^^^^^^^^^^^^^^^^^
> iyear = 1900 + iyear
> else
> iyear = 2000 + iyear
> endif
>
> I'm for trying that out if that sounds OK.
>
> Dave
>