**To**:**ferret_users@xxxxxxxxxxxxxxxxxxx, jpal@xxxxxxx****Subject**:**Re: Time Stuff****From**:**<Russell.Fiedler@xxxxxxxxxxxxxxx>**- Date: Mon, 22 Feb 1999 10:14:54 +1100 (EDT)
- Sender: owner-ferret_users

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

- Previous by thread:
**Re: Time Stuff** - Next by thread:
**Seasonal data on a continuous time axis**

Dept of Commerce / NOAA / OAR / PMEL / TMAP

Contact Us | Privacy Policy | Disclaimer | Accessibility Statement