[CF-metadata] generalizing forecast_reference_time and forecast_period

From: Schultz, Martin <m.schultz>
Date: Wed, 18 May 2011 10:53:38 -0000

Dear all,

    once again I haven't followed the entire discussion carefully, but I sense there is more to the problem than what has been discussed so far:

1) if we define the meaning of "time" as a specific datetime instance on a given calendar, then all time values along a trajectory should indeed be in a form that can be expressed in the usual "days since DATE" units.

2) the trajectory "starting point" (as 4D space-time tuple if you like to get fancy ;-) is a unique characteristic of the trajectory as a whole. This means that within the same model (or interpolation technique) you will always be able to reproduce the exact same trajectory if you know this one location and time. In this sense it is similar to the "reference time" of for example a 3D model run, which is usually expressed as the DATE in the time units attribute. In order to avoid confusion here, I suggest to use the term "trajectory_start_time" (or short: "start_time") here.

3) trajectories can be run forward and backward in time. Therefore the "time" values can be negative relative to the "trajectory_start_time".

4) in the simple case of having one trajectory in the file (equivalent to some output interval from a model simulation), one could easily live with the standard way of setting the reference time (DATE part of time units attribute) to the trajectory_start_time and have the time values express the relatve time shift with respect to the trajectory_start_time.

5) in the more complex case with several trajectories in the file, one option could be to allow for a new DATE value in the time units attribute, such as:
    time: units = 'days since trajectory_start_time'
    string trajectory_start_time(ntraj)
    double time(ntraj, nsteps)
Hence, the term "trajectory_start_time" would refer to a variable rather than a given fixed date.
Not so nice if you have to evaluate a lot of strings every time you use this.

6) Alternatively, DATE would still be an arbitrary reference date, and the trajectory_start_time variable would be an offset relative to this. Hence:
    real_time = reftime + trajectory_start_time + time
This would, however, require some means of expressing the meaning of the "trajectory_start_time" variable, because otherwise any automated system would compute time simply as real_time = reftime + time. Could one use the formula terms for this?

7) Trajectories don't necessarily all have the same length (for example flight tracks of ozone sondes which end when the balloon bursts). Not too careful thinking suggests that one should then either move to hdf or agree on a certain maximum number of "steps" for all trajectories.

Hope this helps a bit,

Martin


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de
Received on Wed May 18 2011 - 04:53:38 BST