[no subject]

[Dave Brown <dbrown@xxxxxxxxxxxx>]

Hi,

I have a large dataset (~ 50 Gig total in 365 files) representing a
year's worth of data in hourly timesteps. Using the Grads-DODS 
server I have aggregated the files such that they appear as a
single dataset accessible via a DODS url. This part works pretty
well and I am impressed with GDS's ability to quickly access data 
across the whole time dimension. However, I have run into a 
stumbling block in trying to provide access to the dataset 
via the LAS. 

The original dataset encodes the time dimension as days since the
beginning of the year, in this case 1990. This means the 1 hour
timestep is fractional --  0.0416666666 days. GDS adjusts the
time unit to "days since 1-1-1 00:00:0.0", so the starting time,
as presented by DODS, is 726469.0. 

The LAS xml for the time dimension, as generated by the addXml.pl 
script using the first file in the dataset as input, 
reads as follows:

<h0001_nc_time units="hour" type="t">
  <arange start="1990-01-01 00:00:00" step="1" size="8760"/>
</h0001_nc_time>

LAS 5.0 read the xml and generated the user interface for this
dataset without problems (*), but when I try to access the data I get
this error from Ferret:

 *** NOTE: Coordinates out of order or missing on axis time at
subscript 2163
 *** NOTE: A dummy axis of subscripts will be used
...
 **ERROR: illegal limits: "FOSSIL" is not in the range T=-8.082E+16
          Axis extremes are T=0.5:8761

So I checked the elements of the time axis around element 2163:

 2162               2163          2164              2165
726559.0416666666, 726559.125, 726559.1666666666, 726559.2083333334


The values are clearly present and in order.
My guess is that Ferret is using the float type to represent the
coordinate values, and that it cannot fully resolve these values, with
the result that they incorrectly appear to be out of order. 

If this is the case, is there anything I can do to work around the
problem? Or am I off the wall and it's something else entirely?
 -dave
 dbrown@ucar.edu

(*) well actually, with some problems, but not I think related to this
issue.