Date

Aug 20, 2014

Attendees

John Clyne, Alan

Agenda

DataMgr discussion

• Discuss Alan's Proposed GUI Changes (See GUIforVDC3.0.pdf)
• Discuss John's proposed DataMgr API changes (currently checked in to the VAPOR_3_0 branch as DataMgr3_0)

Notes

Discussed proposed changes to the DataMgr needed to support the VDC 3.0 API, and attached document (GUIforVDC3.0.pdf) written by Alan.

Proposed GUI Changes to support DataMgr 3.0

The notes below respond to the numbered items in the attached document: (GUIforVDC3.0.pdf)

2. Name collisions can be avoided by simply not allowing a "tab" to mix variables from different DataMgrs. It is not clear that there is a use case that requires renderers to operate on variables from two different DataMgrs (data sets)

4. Coordinate variables WILL be exposed in vaporgui. They are no different from data variables in the sense that they are simply discretely sampled functions that can be operated on with all of vaporgui's visualization and analysis operators

5. For  renderers that operate on multiple variables (e.g. Flow, iso) the possibility of having variables with different compression rates should not be problematic: the number of wavelet coefficients used in reconstruction is hidden from the renderer, and for multiresolution grids the RegularGrid class provides access via user coordinates.

6. The possibility exists that a data variable will have different compression parameters than its associated coordinate variables. For example, a data variable may be compressed, while a coordinate variable may not be. In such an instance the DataMgr will most likely need to support interpolation of  coordinate variable to match the grid dimensionality of the data variable. Handling of grid mismatches by the Python interpreter will require further consideration.

8. Needs further discussion.

9 We should do away with variable indeces and manage variables using their names.

Proposed DataMgr API changes

• Maintaining backwards compatibility with pre-3.0 session files and data sets will take a lot of effort. Our current thinking is to not maintain compatibility. Translators for session files and/or data sets could possibly be developed if there is sufficient demand
• The role of the DataMgr is limited to:

1. 1. Provide an abstraction for accessing data that hides the underlying file format (i.e. allows reading data from VDC, WRF, ROMS, etc)
   2. Cache expensive operations (data reads, calculation of metadata such as domain extents, data range, etc)
   3. Support derived variables created via Python

• To support other needed data functions that are not provided by the DataMgr a helper class (similar to current DataStatus) class is required. The methods/functions provided by this helper class are TBD.
• The 3.0 DataMgr provides variable access methods that are based on user, not voxel, coordinates. Much of the 2.x code is spent converting user to voxel coordinates so that appropriate parameters can be passed to DataMgr::GetGrid(). Initially, the new DataMgr will only support a user coordinate based access method. We can add a voxel coordinate based access method if needed.

Action Items