[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[THREDDS #RNZ-598093]: 360 day year support?

Hi Steve,

OK. Everything sounds good and I'll try to answer and clarify the following.

> I think this would make it CF compliant but I guess that doesn't do much
> for us yet if THREDDS doesn't do anything with the calendar attribute. Do
> you know if there are any plans for adding this in? Timeframe?

The THREDDS server probably doesn't need to understand the calendar attribute. 
Instead, it is the client software (e.g., ToolsUI or ncWMS, which is a client 
wrt this dataset) that needs to understand the meaning of the calendar 
attribute in its interpretation of this dataset. Both ToolsUI and ncWMS are 
based on the netCDF-Java library and though it understands a lot of CF, I am 
not sure if it understands the "360 day" calendar. I'll look into that tomorrow.

How will you or others be interacting with this dataset? 

Ethan


Steve Cousins wrote: 
> Hi Ethan,
> 
> On Tue, 2 Feb 2010, address@hidden wrote:
> 
> > Hi Steve,
> >
> > Let me see if I understand what you are doing. It sounds like you are
> > aggregating your data files using a "joinExisting" aggregation on the
> > dummy time variable you added to each dataset. Instead of defining the
> > time values in the dummy time variables, you are defining them in the
> > XML. (Is it just easier that way or is there some other reason?)
> 
> Yes. This is the case. Here is the aggregation section:
> 
> <aggregation dimName="time" type="joinExisting">
> <scan
> location="/sginas/home/lshi/ST_BLENDED_FORCING_RESULT/variable_sets/"
> regExp=".*avg_BD_V1_[0-9]{4}\.[0-9]{4}\.nc$"/>
> </aggregation>
> 
> I was going to put the actual hour value in each file but I tested a small
> aggregation doing with 0.0 values in the data files and the following in
> the XML:
> 
> <variable name="time" shape="time" type="float">
> <attribute name="units" value="hours since 1991-01-01 00:00
> UTC"/>
> <values start="0.0" increment="73.0"/>
> </variable>
> 
> and it worked. This made it simple to add the time variable in, although
> it wouldn't have been that much more to just increment it by 73 each time
> I admit. Since I wasn't sure about using 72 or 73 and how it would change
> with a 360 day calendar I thought it best to just leave them at 0 and work
> with the XML. Once we settle it down I'll try to get people to put it all
> in the file.
> 
> 
> > Back to your main question: THREDDS aggregations don't understand
> > different calendars. However, the CF convention describes how to specify
> > various calendars in a netCDF file. So, by getting the time values and
> > certain attributes correct, you should end up with a 360-day calendar
> > dataset according to CF.  Section 4.4.1 "Calendar" in the CF
> > specification details what you'll need with some other good info, if
> > your not up on CF time coordinates, in section 4.4 "Time Coordinates":
> >
> > http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#calendar
> > http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#time-coordinate
> >
> > I'm not that familiar with this part of CF and it isn't clear to me how
> > to define your time values. There aren't any examples showing how the
> > 360 day year interacts with the "units" value which according to udunits
> > is a "mixed Gregorian/Julian calendar". The best bet here is probably to
> > post a question on the CF mailing list. You can subscribe to that from
> > the "Discussion" section of the CF site (http://cf-pcmdi.llnl.gov/).
> 
> 
> I'll take a look. It looks like I want:
> 
> <variable name="time" shape="time" type="float">
> <attribute name="calendar" type="string" value="360_day"/>
> <values start="0.0" increment="72.0"/>
> </variable>
> 
> I think this would make it CF compliant but I guess that doesn't do much
> for us yet if THREDDS doesn't do anything with the calendar attribute. Do
> you know if there are any plans for adding this in? Timeframe?
> 
> 
> 
> > One other aggregation note. If your file names indicate the time for
> > that file, you may be able to use a "joinNew" aggregation instead of
> > "joinExisting". You could then use a "dataFormatMark" attribute to
> > extract the run time of each file. Though I guess you'll need to figure
> > out what the time values should be according to CF before proceeding
> > with this. Anyway, more info on "dateFormatMark" in section "Extracting
> > date coordinates from the filename" of the aggregation page:
> >
> > http://www.unidata.ucar.edu/software/netcdf/ncml/v2.2/Aggregation.html
> 
> 
> This is good to know. Unfortunately the file names are like:
> 
> avg_BD_V1_YEAR_SLICE.nc
> 
> where SLICE is from 0 to 119. If some simple multiplication could be done
> to multiply the slice by 3 then it would work:
> 
> DateFormatMark: avg_BD_V1_#yyyy(DDD*3)
> 
> or something like that. But I don't see that ability in the Java
> documentation. It isn't a big deal I don't think but I'll pass this
> information along to our modelers so they can think about changing the
> file names to Day of Year instead of slice number.
> 
> > Hope this all helps,
> 
> Yes it does. Thanks very much.
> 
> Steve

Ticket Details
===================
Ticket ID: RNZ-598093
Department: Support THREDDS
Priority: High
Status: Closed