Hi Rich, Balaji, David, Frank,
You can probably guess the drums that I'll be beating:
1. to make sure there is enough emphasis on *interoperability*--
think about general clients as well as the data generators.
2. to make sure that the benefits of the proposal are weighed against
its down sides (a multiplicity of encodings to do the same task
always has some down sides)
3. to clarify why the current CF encodings cannot address the use
cases that have been identified
The current CF encodings allow an arbitrary named-units "tic"
resolution, an arbitrary origin, and an arbitrary datatype. e.g.
double TIME(TIME) ;
TIME:units = "milliseconds since 1981-01-13 12:15:00" ;
One advantage cited for the two-integer encoding was "avoiding round off
problems where you get 23:59:59 instead of 00:00:00" Can we clarify?
As I ponder this, all of the examples that I come up with are coding
issues in clients, rather than the precision of the CF file. After all,
one can go to the extreme of
int TIME(TIME) ;
TIME:units = "hours since 1981-01-01 00:00:00" ;
if this is a concern. And for the aside discussion of "non-rational"
time steps, integer round-off is by definition not an issue. (I'm
taking "non-rational" in a vernacular sense to mean a non-integer
fraction of some standard unit).
It sounds like the most significant goal of the new proposal is to add a
second word of precision (i.e. a 64 bit integer). The gain from this is
presumably to have both high resolution in time and very large time
spans. The use case that Rich presented is "millisecond precision over
millennia, so you can do things like paleo earthquake simulations".
Sounds interesting ... but a new requirement to me. Are there use cases
where a single "file" (or aggregation) needs to contain millisecond
precision over millennia time scales? Are there alternative ways to
structure the data that might work as well?
A down side to the double integer proposal is that the double integer
array cannot even be a "coordinate variable" in the traditional netCDF
sense. We 're potentially making some simple things in CF a lot
messier. If the 64 bit precision is a real requirement, can we think of
other ways to get 64 bit integer precision, say, in netCDF 4?
- Steve
==================================================
V. Balaji wrote:
> David Stuebe writes:
>
>
>> I support Rich and Balaji in creating a two integer time standard. I think
>> the tick_length as a attribute is a great idea for non-rational times, and I
>> agree with Rich that the major unit should be specified by the user - Days,
>> Second, Hours, Years etc...
>>
>
> I would still prefer if the major unit were not calendar- (or planet-:-)
> specific -- seconds, minutes and hours are universal constants and
> should be the only ones allowed -- but hey, I'll go with the flow.
>
> Just to be clear: the 'tick' allows you to be precise about fractions
> of time units, but not 'non-rational' times: 1/3 second is rational. To
> be equally clear, all floating-point numbers are rational, so I don't
> think this is an issue. If you really need a model with a timestep of
> 'pi' seconds, I think you have a problem anyway, with or without CF...
>
>
>> Concerning Days and earth-centric time units in UDUNITS
>>
>> Days - or rather (Modified) Julian Date as defined using a two integer time
>> variables is an extremely practical method of storing time information for
>> many, but not all applications. A standard for time and date which includes
>> the needed definition of Day and time origin is important, (leap seconds
>> aside) although not general as you pointed out for ET models... A definition
>> of Day should remain in UDUNITS. Is there a standard for setting time origin
>> for MJD and JD?
>>
>> I found it difficult to set time origin using an attribute, the string gets
>> complicated. I would suggest a seperate variable if it does not conform to
>> some recognized standard like JD or MJD...
>>
>> About the choice of Millisecond as the minor unit, it is not arbitrary for
>> storing MJD dates, there are more Microseconds in a day than can be stored
>> in a 32-bit integer. To avoid dealing with long integers, I choose
>> Milliseconds for FVCOM output, though in the model, the Time Type/Class uses
>> 64-bit integers and microseconds.
>>
>> I don't see a type name for 64-bit integers in the NETCDF 3 docs - am I
>> missing something?
>>
>> David
>>
>>
>
>
--
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
"The only thing necessary for the triumph of evil is for good men
to do nothing." -- Edmund Burke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20071102/1802ff84/attachment-0002.html>
Received on Fri Nov 02 2007 - 14:05:08 GMT
