Hi all,
I have been feeling uncomfortable about this proposal too, mostly
because of the complications I foresee, but have no time to respond
right now. Steve's arguments resonate with me, so I'll be interested in
hearing the responses.
Karl
Steve Hankin wrote:
> 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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Fri Nov 02 2007 - 14:37:10 GMT
