Ensemble Navigation

Just a place to keep some thoughts on how to support navigation of ensembles of databases in VisIt.

Currently, VisIt has a sort of built-in notion of one kind of ensemble; a time series. A time-series is typically regarded as a group of time-states within a single database. A time-series supports a notion of a first and last state (more generally, extremums) as well as next and previous states. The VCR controls in VisIt's main VisIt GUI panel are a manifestation of VisIt's built-in support for this kind of ensemble.

More generally, however, ensembles are just collections of related results. The dependent variables of a simulation are the computed results while the independent variables represent the inputs to the simulation for which a given set of results are computed. So, the independent variables of a collection of related results kinda sorta defines an ensemble space or state space.

  • A time series is a one-dimensional ensemble space. It supports notions of extremums such as first and last and incrimentation such as next and previous or incrimentation by step size such as +=delta or -=delta.
  • An uncertainty qauntization (UQ) ensemble might be one in which two parameters, say thickness of copper (A) and initial velocity (B) are varied as the independent variables. This could be viewed as defining a 2-dimensional ensemble space.
    • If results are produced in such a way A is fixed and B is varied in the set {B0,B1,B2,…Bn} and then A is fixed at another value and B is varied by the same set of values, {B0,B1,B2,…Bn}, then the ensemble space would define a rectilinearly organized set of members of the ensemble. Given any member in such an ensemble, it would be natural to want to move to the next and previous members along either the A or B parameters. It is also natural to think of the 4 corners (extremums) of this ensemble space. One might even reason its possible to interpolate between results
Rect2d ensemble2.png
  • Alternatively, a UQ algorithm might do a more or less scattered sampling of pairs of A,B values. In this case, the ensemble space can still be viewed as two dimensional. However, its harder to try to define notions of next or previous to navigate through the ensemble. The extremums are defined by the convex hull of the points. Its also possible to reason that interpolating between computed results in this ensemble might make sense.
Ensemble scatter2.png
  • Alternatively, a UQ algorithm might proceed in such a way that the independent variables are changed depending on results computed for previous values. For a given result A0,B0, a UQ algorithm might decide to vary both A and B for a next try. It might wander along a trajectory for a while computing several results for A,B pairs and then decide to backtrack to A0,B0 and work along a new and different trajectory. In this case the ensemble space is still two dimensional. However, the notions of next or previous are a little more interesting to consider.
Ensemble trajectory2.png
  • A debugging output from a unstructured adaptive meshing code might include intermediate refinement and coarsening steps that the code iterates through before it advances in time. So, for a given timestep, there is a sequnce of related refinement and coaresning outputs. It may be worthwhile to make it convenient to move from one timestep to the next but not from a refinement step at one timestep to a refinement step at another timestep.
Ensemble amr2.png
  • Another possibility is maybe a hiearchy of graph-like state-spaces. This case is different from the others in that its more like a graph of graphs. Navigation might involve first moving between the lettered super-states and then between the numbered sub-states inside of a given lettered super-state. This is kinda like the adaptive meshing case in that the super-states would be different time steps while the sub-states would be different refinement and coarsening steps. But, its a little more general in that both super-states and sub-states are organized more or less like a graph instead of a linear series of steps. This of course can still be represented by a single graph data structure, I think. But it suggests we have different kinds of edges. In this example we have inter-letter edges and inter-number edges.
Ensemble navigation5.jpg
  • A categorical ensemble would have arbitrary labels for each state and, as well, probably arbitrary ways of defining walks through the available states. Think for example, of the various categories of arbitrary polyhedral data or CSG example data in our test suite. These all basically form a sort of categorical ensemble.

Generalization of Ensemble Spaces for VisIt

From these examples, the basic work to generalize our notion of an ensemble space in VisIt is to support and define a general graph for the ensemble space. Note that implicit within this statement is the assumption that the state space does not represent such a large mesh that it demands support for specialization for regular topological structures. In other words, its ok to treat the state-space mesh as always being an unstructured sort of thing.

  • Nodes in the graph represent a given combination of independent variables.
    • Nodes could be assigned arbitrary names (optional)
    • Nodes could be assigned one or more coordinates (e.g. index, time and cycle for the 1D time ensemble space) which in many cases would be the values of the independent variables for the associated state. In the examples above, each node could be assigned an A value and a B value serving as a 2-component coordinate of the state in the two dimensional space.
    • There is always a natural numbering of the nodes of the ensemble graph, 0…NumNodes-1
  • Directed dges in the graph can represent relationships between the nodes
    • Labels can be assigned to edges to give a sense to the user of what it means to walk along that edge in the graph. For example, the label next in a time series could suggest to the user that hitting that button moves to the next timestep.
  • Various traversals or explicit walks of the graph can be used to define sequences for animations.
  • VisIt's current notion of a time series is replaced with a graph where
    • Nodes represent individual time states.
    • Nodes always have coordinates of timestate but can, optionally be assigned cycle or time coordinates
    • There is a node labled first and another node labeled last (by default these are nodes with coordinates timestate==0 and timestate==NumNodes-1
    • Every node has two directed edges, one labeled next and another labeled previous
    • If we want to series to be periodic, the first node's previous edge takes the user to the last node and vice versa
    • If we want the series to be aperiodic, the first node has no previous edge and the last node has no next edge
    • VisIt and Ensemble Graphs
      • VisIt will have the ability to construct a time-series ensemble graph automatically from existing notions of .visit files and *database files, etc.
        • When an ensemble graph VisIt is operating on meets the requirements for a time-series, VisIt's VCR buttons are enabled.
      • Alternatively, VisIt can open an ensemble graph in which all the nodes, edges, etc are explicitly handed to VisIt (e.g. defined external to VisIt by some other application)
      • VisIt will have the ability to do visualization of the ensemble graph
      • VCR-like buttons are replaced with a generalized button set (derived from the ensemble graph) where button labels vary depending on current state at which VisIt is viewing in the ensemble and the out-directed edge lables available from that node
      • A pick operation on a node in a visualization of the ensemble graph will take VisIt to the specific state of the ensemble.