Re: Time Stuff

[<Russell.Fiedler@xxxxxxxxxxxxxxx>]

Jeremy,

> 1.  In my NetCDF files, I define time in hours as starting from
>     01-JAN-0000 (e.g. 17419896 = 01-APR-1988 00:00).  When I plot these 
>     data files, the date that Ferret lists in the top left hand corner of
>     the plot is exactly 2 days later than it should be (Ferret says
>     03-APR-1988 00:00).  Upon testing the same file in GrADS, I found that
>     the date is exactly what I expect it to be.   Any ideas of why this is
>     happening?

Not too sure about this but I'll hazard a guess that it's related to the answer to the second problem.
> 
> 2.  Some of the datasets that I use contain hourly values of data (with
>     times defined similar to above).  When I plot a time series of these
>     data, ferret seems to combine 3 or so hours worth of values into one
>     time and then skips few times plotting 3 more hours worth of different
>     values into another time, and so on. For example, if I type 
>     'plot/i=50/j=50/l=1:3 ts', I get a verticle line.  If I type 
>     'plot/i=50/j=50/l=1:6 ts', I get two connected verticle lines.  I
>     tested the data in GrADS, and everything appears as I think it should
>     appear.  This problem does not occur when I plot data that have a time
>     resolution coarser than 3 hours or when I average the data.  Any ideas
>     of how to overcome this problem?

This is a problem with the representation of large integers in floating point
format. 4 byte reals can't represent anywhere near the same range of integers
as a four byte integer. IEEE754 arithmetic (type float in netCDF) has a 23 bit
mantissa so exact integer arithmetic cuts out at about 8 million. Try the following fortran program on a IEEE based machine

        i=17419896
        x=real(i)
        j=x
        y=x+1
        k=y
        z=y+1
        m=z
        write(*,*) i,x,j,y,k,z,m
        end
% f77 acc.f
acc.f:
 MAIN:
% ./a.out
   17419896    1.74199E+07  17419896    1.74199E+07  17419896    1.74199E+07
   17419896
% f77 -r8 acc.f         (force double precision)
acc.f:
 MAIN:
% ./a.out
   17419896    17419896.000000  17419896    17419897.000000  17419897
     17419898.000000  17419898


Clearly, you need to be able to force double precision arithmetic to be done
in Ferret (obviously GraDS is getting it right) OR get inside the range of
exactly representable integers. Either represent the time value as a double
precision variable or, if this doesn't work (Ferret may pack this value to
real*4 anyway), you will have choose a much later starting point for your
time offset.

Cheers,
Russ