IDataArray or (DataArray) needs meta-data to describe certain kinds of component configurations

[imikejackson]

The issue comes to light when a user creates a 6 component array which is really a tensor but currently the XDMF writer assumes it is a pair of 3 RGB vectors. We also have this issue with 2 component arrays. IDataArray could implement a class enumeration to describe the type of data. We would also need to update just about every filter to also set the type and further expose it to the user in the CreateDataArray filter. Possible enumerations are:

Scalar | Vector | Tensor | Tensor6 | Matrix | GlobalID

We could also add RGB | RGBA | COLOR as possibilities.

Which come from this page http://www.xdmf.org/index.php/XDMF_Model_and_Format#Set

We could follow the XDMF naming and call it the "AttributeType" but I am not sure that conveys what it is. "ArrayType" does not really work either as I would think that means float, int,....

ComponentConfiguration, ComponentType?

We could also at least put in the infrastructure but slowly work on updating those filters that specifically need to set a description.

[mmarineBlueQuartz]

How about calling it "AttributeCategory"? Category is distinct enough to not be confused with data types like float and int, and Component sounds like it's describing individual component properties, i.e. component (0,0) is a Vector, but component(0,1) is a complete RGB value despite how an RGB value should span three components by itself.

I would shy away from using Array in the enumeration name. Not only is that part of the class name, but every use of array in DataArray.hpp refers to either a DataArray<T>::Pointer or a T* array. It would be better to shorten it to just "Category".

[imikejackson]

DataCategory?
ComponentCategory?

[imikejackson]

ComponentType

[mmarineBlueQuartz]

VTK also calls this enum AttributeTypes. I'm not sure if that matters to us, but I can live with ComponentType. Looking through DataArray.hpp, the closest we get is component dimensions and getType(). As long as ComponentType and data type are distinct, I don't think we'll be inconsistent.

[imikejackson]

I agree. Using AttributeType might be confusing with AttributeArray? AttributeMatrix? ComponetType is pretty close in meaning to what we want. I think we should change the API to be "getDataType()" and "getComponentType()".

Thoughts?

[imikejackson]

using EnumType = uint32_t;
enum class ComponentType : EnumType
{
  Scalar = 0,  //!<
  Vector = 1,  //!< 3x1 Matrix
  Tensor = 2,  //!< 3x3 Tensor
  Tensor6 = 3,  //!< 6x1 Voight Notation Tensor
  Matrix = 4,  //!< MxN matrix
  GlobalID = 5,  //!< Like a Scalar
  RGB = 6,  //!< 3x1 UChar array
  RGBA = 7,  //!< 4x1 UChar array
  Unknown = 8  //!< 
};

[mmarineBlueQuartz]

I am in favor of getDataType() and getComponentType(), though I would suggest changing the description of GlobalID to something other than "Like a Scalar". "size_t identifier", "Integer identification number", "Unique ID", etc.

[imikejackson]

We will need to update the API to create Arrays in order to set the ComponentType when creating. Or we can take a guess based on the comp dims that get passed in? This would hit every filter and require manually looking at every filter to ensure the proper component type is being assigned.