comments on:
Days?,
non-rational time - my mistake
two integer time in netcdf4
>
> > 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.
>
Is Modified Julian Day out of fashion then?
>
> 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...
>
Ah - my mistake... sorry for the confusion.
>
> 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
>
I would think there is a much better way to do this with a compound types in
netcdf 4 (coordinate variable issue) similar to what I use in our FVCOM
model. On the down side, I am not very good at c, and the interface for
compound types does not seem to exist yet for fortran and f90?
INTEGER, PARAMETER :: itime = SELECTED_INT_KIND(18)
TYPE :: TIME
INTEGER(itime) :: MJD !! MODIFIED JULIAN
DAY
INTEGER(itime) :: MuSOD !! MicroSECOND OF
DAY
END TYPE TIME
For instance, I have used this as a type in our F90 model and it seems quiet
sufficient... could something similar be done in netcdf4 using types?
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20071103/078b18f7/attachment-0002.html>
Received on Sat Nov 03 2007 - 09:57:54 GMT
