P.S. I neglected the obvious further simplification: replace "t(o)"
with "t(t)". Time becomes a simple netCDF coordinate variable in the
synchronized representation of trajectories. Similar for synchronized
profiles and time series.
===========================
On 10/13/2010 10:39 AM, Steve hankin wrote:
Hi All,
2 cents: Since this is a new twist on previously discussed feature
types, the tires of alternative approaches probably deserve to be
kicked. What's special about this use case is that the trajectories
are all synchronized in time. (Though with differing start/stop
times.) Analogous cases exist in profiles -- for example the Levitus
ocean profile collection has all been interpolated to common depths.
Similarly, time series collections are commonly synchronized.
The synchronization of coordinates opens a potential door to great
simplicity of representation.
metadata(i) data(i,o) x(i,o) y(i,o) z(i,o) t(o)
where i is the instance (which of the trajectories), o is simply the
time index. The possible costs are proliferation in numbers of ways
to represent similar things and file size. The question that I'd be
inclined to ask of Ute and Rich would be a judgment call on the cost
in file size that would result from filling missing values at the
start/end of each individual trajectory. Optionally the metadata
could include
tstart_index(i) tend_index(i)
This representation seems _the simplest from the standpoint of
application code (reading)_. Synoptic view are simply projection at
fixed "o" index; the history of an individual trajectory is simply a
projection at a fixed "i" index.
-----
For each of the three basic structure -- time series, profiles, and
trajectories -- discussed at
https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions we
have three approaches: multi-dimensional, ragged contiguous, ragged
indexed. ("flattened" omitted here). Effectively what I am kicking
the tires on here is a 4th approach: a "synchronized representation",
which would be the simplest of all of them. If we replaced "t(o)"
with "t(i,o)" above the "synchronized representation" generalizes into
the "multi-dimensional representation" of trajectories.
By the way, it is quite likely that *none *of the above precisely
addresses the needs of the model that is producing the data. Does
that model know in advance what the maximum number of tracer particles
will be? If that number is known, then the "Ragged array (indexed)
representation" of trajectories is arguably _the simplest from the
standpoint of model (writing)._ (And already documented. ;-) )
- Steve
============================
On 10/13/2010 5:49 AM, Jonathan Gregory wrote:
Dear Rich
With the approach you suggest, if you wanted to obtain all the
particle positions at a particular time step, would you need to read
all tindex for all particles? (I'm a little fuzzy on what the CDL
would look like...)
No, I don't think so. Either of John's proposed packing mechanisms would
allow you to get just the tindex (and x y z) that applied to a particular
particle without reading the others.
Cheers
Jonathan
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
