[Thread Prev][Thread Next][Index]

Re: Accessing a GDS dataset with the LAS



Hi Joe,

I just asked Dave for the same thing moments ago ...  Answer attached.

    - steve

==============================

Joe Sirott wrote:

> Hi All,
>
> I believe that Ferret uses double precision values to represent axes, so
> something else must be going on. Can you release the DODS URL of this
> dataset? That would help a lot.
>
> Joe W. -- in general, it would be better if GDS used a time origin that is
> past the date where the calendar changed from Julian to Gregorian as
> different applications interpret earlier dates differently. For instance,
> Ferret assumes that 1/1/1 is on a Gregorian calendar, while GrADS assumes
> that 1/1/1 is on the Julian calendar. It might be convenient to use the
> Unix epoch instead (January 1, 1970).
>
> At 11:51 AM 2/8/2002 -0700, Dave Brown wrote:
>
> >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

--
Steve Hankin
NOAA/PMEL, 7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080 -- FAX (206) 526-6744

--- Begin Message ---
Hi Steve,
Oops, sorry, my apologies! I guess my theory was wrong. 

The dataset is TEST_SSS on
the GDS site: http://dataportal.ucar.edu:9090
It's called Test-SSS on the LAS site:  http://dataportal.ucar.edu/las5

If you want to see the XML or an ncdump of the data I can send it to you.
 -dave
 dbrown@ucar.edu


--- End Message ---

[Thread Prev][Thread Next][Index]

Dept of Commerce / NOAA / OAR / PMEL / TMAP
Contact Us | Privacy Policy | Disclaimer | Accessibility Statement