On Fri, 8 Feb 2002, Joe Wielgosz wrote: > Jennifer M. Adams wrote: > > > Dave Brown wrote: > > > > > >>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. > >> > > > > Hi, Dave -- > > > > My understanding is that the metadata accompanying a GDS > > dataset is generated by GrADS, so it may be relevant how you > > describe the original dataset to GrADS in order to serve it > > with your GDS. It sounds like somewhere in there the time > > zero got changed from 1-1-1990 to 1-1-1. Can you point me to > > the DODS URL where this GDS data set is located? Would it be > > possible for me to access the original data directly with > > GrADS using my account on motherlode at NCAR? > > > > > Perhaps I can help clarify this part a bit. Nothing is going wrong here. > In fact, the only time units the GDS knows about are "days since 1-1-1 > 00:00:0.0". Time values extracted from datasets are automatically > converted to these units in the GDS, before being sent. > > This is an artifact of the way time values are obtained in GrADS - it > was simpler just to pick a standard set of units rather than trying to > handle each dataset individually. > > I don't know if that helps, but good luck. > > And please let me know if the GDS needs improvement in this area. > > - Joe > Thanks for you input, Joe. This is what I had surmised from looking at several datasets served by GDS. > > > >>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> > >> > > > > It's been a while since I've thought about LAS xml coding, > > but here the units are hours, so that may be one source of > > error. Are you describing the original data set (in 365 > > separate files) or the GDS data set (1 DODS URL) to the LAS? > > > > Well, the point is that LAS software (specifically ui/perl/LASNetCDF.pm) automatically made a correct conversion from time specified in the NetCDF in fractional days into hours in order to generate this xml. The LAS user interface understands the conversion, and I believe that Ferret does as well. But my hunch still is that Ferret is treating the coordinate values as float types, and therefore is only able to resolve the values to between 6 and 7 digits of precision, not enough in this case. > > > >>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 > >> > >> > > > > Does it change anything if you skip over the LAS and just > > try to read the DODS URL with Ferret? > > I guess I should try that... > > Perhaps the LAS and Ferret experts from PMEL will have > > additional insights... Indeed. -dave dbrown@ucar.edu