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

20000119: imgi2gm.f



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
>