View source for VtkArray Changes for In-Situ Array Mapping

There are plans to replace the vtkDataArrays with the vtkArray hierarchy.  As we make this change, we should also consider the possibility of changing the layout of the memory used in the class.  This is mostly important when considering using VTK ''in-situ'' with simulation.  The solver may well store data in a layout different than that implicitly specified by VTK.  We wish the vtkArray hierarchy to encapsulate the layout of the internal memory and make it straightforward to provide a new subclass of vtkArray that will naturally be used properly by filters without deep memory copies.

== The Main Problem ==

The main problem with the vtkArray hierarchy with respect to switching memory array layouts is the existence of the method vtkDenseArray::GetStorage().  This method returns the raw array used in vtkDenseArray, and it is assumed to have a particular layout.  The problem is that if one is to subclass vtkDenseArray to support a different layout, this class would have to override this method to allocate a new array and copy the data.

There are legitimate reasons to get the raw array from a vtkDenseArray.  However, the interface should discourage this use unless actually necessary.  The interface should make clear that an allocation and deep copy might occur.  For the filter programmer, it should be easier (and efficient) to operate directly against the interface of the array itself.

To use vtkArray in place of vtkDataArray, the implementation (at least initially) will reimplement the vtkDataArray hierarchy to interally use vtkArray.  The vtkDataArrays should also deprecate the GetPointer and GetVoidPointer methods for the same reason.  The correct way to get these pointers should be to get the underlying vtkArray and getting the array from there.

== Review of vtkArray Hierarchy ==

The hierarchy of vtkArray types is (conceptually) as follows.

<graphviz>
digraph {
fontsize = 9
fontname = Helvetica
rankdir = LR
node [ fontsize = 9 fontname = Helvetica shape = record height = 0.1 ]
edge [ fontsize = 9 fontname = Helvetica ]

// 1. Class declarations

// 2. A is the superclass of B
edge [ arrowtail = onormal arrowhead = none ]
vtkArray -> vtkTypedArray
vtkTypedArray -> vtkDenseArray
vtkTypedArray -> vtkSparseArray

// 3. A owns the lifetime of B
edge [ arrowtail = diamond arrowhead = none ]

// 4. A has a pointer to B
edge [ arrowtail = odiamond arrowhead = none ]
}
</graphviz>

For the purposes of this conversation, we will be talking exclusively about the vtkDenseArray branch.  This is the type of array most likely used in data set processing as they typically store a field value per point or cell, and the dense array is the most efficient structure for that.  It may make sense to do a similar thing for sparse arrays.  Then again, something capable of iterating over a vtkSparseArray is pretty sure to also be able to handle a vtkDenseArray.  In that case, it makes more sense to downcast only to vtkTypedArray, in which case it is straightforward to just create a new subclass of vtkTypedArray.