# 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

- 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

- 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.

- 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.

- 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.

- 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.

- 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.

- Labels can be assigned to edges to give a sense to the user of what it means to
- 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.

- VisIt will have the ability to construct a time-series ensemble graph automatically from existing notions of .visit files and *database files, etc.