Sketch at a trajectory service for ROMS ocean simulation data

The process we've been using so far looks like this:

Inputs:

1. Single 4-dimensional (lon*lat*depth*time) NetCDF file from ROMS, with fields:

   time	(sampled at some interval, every 6 hours)
   lon	(degrees east, currently positive (Monterey Bay, CA centered around +238 (!) deg))
   lat	(degrees north)
   depth	(meters)
   u	(eastbound zonal current, m/sec)
   v	(northbound meridional current, m/sec) (note that ROMS does not appear to report vertical velocities, or at least they haven't been given to us: no "w" so far)
   temp	(temperature (C))
   salt	(salinity (units unspecified, maybe gm/liter? Values around 33))

   The ROMS computation apparently uses "sigma coordinates" internally to represent depth, in which the depth where the computational grid provides a fixed number of levels between the sea surface and the sea floor

   The example file we have contains a 131x141x30 (lon x lat x depth) grid, though the computational setup doesn't care about the resolution. Field values beneath the sea floor are replaced with "missing" values (currently -9999). Since the depth extends to 5000 m, there are lots of missing values in shallow water.

2. Trajectory controls, including
   • Seeding strategy: how to choose sample points, e.g.:
     • uniformly distributed over some volume,
     • distributed on a regular grid,
     • concentrated in some areas (central location and central-vs-peripheral density),
     • all seeds released at once or periodically,
     • total number of trajectories to follow (we've often used 5000-30000 or so).
   • Output sampling interval: how often (in time) to report a new trajectory point. All trajectories have constant sampling intervals at present.
   • Which other attributes to report at each sample point, for example, "temp" or "salt". Also, some quantities with special names can be derived from the fluid flow, such as "speed" or "vorticityZ" or "twist" (integral of streamwise vorticity, useful for making twisting ribbons).

   Processing Steps

   Service users wouldn't need to know about these processing steps, but I'll describe them here:
   • Split the 4-D netCDF file into a series of 3-D netCDF snapshots, optionally doing temporal interpolation.
   • Compose the trajectory control file. This depends on user-specified values from (a) and (b) above, and on some internally computed things, e.g. scaling factors which depend on the grid resolution, in order to turn the spatial coordinates into uniform units.
   • Calculate the trajectories. For each output timestep, this produces a ".pb" file giving floating-point position and attribute values (salt, etc.) for each trajectory. In case these might be directly useful, the ".pb" format is described here.
   • Assemble corresponding points into trajectory curves. Effectively transposes the series of .pb files: where the .pb files gather together all point samples at a given time, we want to group these into trajectories, each representing the evolution of one seed point over time. The (single) .traj file contains all the resulting trajectories.

     The ".traj" format is described here.

   Other Stages

   In our visualization process are other steps (done in Alex's Maya plugin) which aren't included here, including
   1. mapping (some subset of) sample attributes into visible quantities such as color or opacity, or
   2. placing smooth tubes or ribbons around each trajectory arc,
   3. selecting subsets of the available trajectories based on attribute value or the fact that they pass through a given region of space/time; we've computed them in large batches, and sometimes depended on interactive filters to choose interesting subsets.
   Some portion of the above could be included with the trajectory service -- would that be useful? Without at least (a) and probably (b), the output will be a bit abstract, not representable as a conventional graphical object. Since we used Maya for these stages, our processing wouldn't be directly usable here, though providing some version of (a) and (b) wouldn't be hard.