Time dependent StateItemSpec aspects

[tclune]

Export spec changes

• aspects:
  1. geom
  2. bracket (/dev/null)
  3. vertical grid
  • number levels
  • coordinates
  4. precision
  5. units
  • frequency/accumulate
• aspects that do not change
  • ungridded dimensions
  • private info
  • shared info

Do we need a coupler (not allowed if time varying)

• Exporter must identify time-varying aspects in advance
• initial coupler may be degenerate

actions

• consequences propagate during invalidate phase
• action aspect does not propagate
  • regrid action does not propagate new geom
  • vertical regrid does not propagate new vgrid
  • interpolate (bracket) does not propgate num fields
  • precision action (copy action) does not propagate new precision
  • units convert action does not propagate new units
  • frequency change disallowed (?)
• action will usually need to be re-initialized for changes in its aspect
• order of actions matters here
  • {regrid, time interpolate, vert regrid, precision, units, accumulate}
    • maybe better? {units, precision, regrid, time interpolate, vert regrid, accumulate}
  • must only handle aspects of actions that follow
• action will sometimes need to be re-initialized for orthogonal changes
  • regrid action reinitialize for
    • change geom
    • change precision
  • time interpolate
    • change bracket
  • vertical regrid action reinitialize for
    • change vgrid (num levels, units, dimensions (PLE vs ZLE), staggering (PL vs PLE))
    • change vgrid coordinates (e.g., update PLE)
      • update() on "extra" couplers will return current coordinates
      • but no way to know if they are "new"
      • maybe update() should be a logical function that returns true when "new"
        • may not be possible? (I think it is ok)
    • change precision
  • copy action (precision)
    • change precision (trivial) (SELECT CASE in field utility layer)
  • convert units
    • change units (SELECT CASE in action)
  • accumulate action
    • cannot happen
    • reinitialized for other reasons ...

Import spec changes

• Must have unique extension (coupler) from source
  • otherwise couplers will be forced to support divergent exports upon changes
  • needs enforcement mechanism
  • tricky to put into existing logic
• aspects:
  • geom
• maybe disallow vertical regrid coupler in this case

actions

• consequences propagate during update phase (reverse flow)
• accumulate action
  • propagate new grid
  • error if mid-accumulation?
    • disallow if not instantaneous?
• units action
  • no issue
• precision action
  • no issue
• vertical grid (hopefully mirror?)
  • propagate new grid
  • propagate internal couplers ... (ugh!)
• bracket
  • trivial
• geom
  • do not propgate
  • recompute routehandle

Support layers

FieldDelta

• Given 2 fields encapsulate the changes required to go from one spec to the other
• update_field() will change necessary metadata for a delta
  • will reallocate (in place) if necessary
  • reasonably well tested

FieldBundleDelta

• analogous to above

Q: Encode possibility of time variability in ItemSpec?

[tclune]

Some (half-baked) thoughts about dealing with the above:

• Introduce abstract base class StateItemSpecAspect (name?)
  • Hopefully existing filtering can be made a method here
• Subclass for each aspect
• StateItemSpecs define which aspects are supported, and in what order they are processed
  • There is no fundamental reason that the ordering has to be the same across specs
  • Some specs are very limited in which aspects they support anyway: e.g., BracketSpec
• Actions get new methods:
  • specify which aspect is handled (screams for unification of action and aspect?)
    • generic coupler uses this to ignore those aspects when determining update to export field
  • specify which actions trigger re-initialization
    • generic coupler uses this to send re-initialization request to action
    • alternatively coupler sends the delta set to action and action self-determines to do update