vtkAffineArray

Development
1

in a ParaView I/O plugin for particle data, I am attempting to replace this simple piece of code creating the connectivity list for a POLY_VERTEXCELL (code inspired from vtkConvertToPointCloud)

  std::vector<vtkIdType> polyVertex(N);
  std::iota(polyVertex.begin(), polyVertex.end(), 0);
  vtkNew<vtkCellArray> verts;
  verts->InsertNextCell(N, polyVertex.data());
  output->SetVerts(verts);

by a new code using a vtkAffineArray

vtkNew<vtkAffineArray<vtkIdType>> polyVertex;
polyVertex->SetBackend(std::make_shared<vtkAffineImplicitBackend<vtkIdType>>(1, 0));
polyVertex->SetNumberOfTuples(N);
vtkNew<vtkCellArray> verts;
verts->SetData(1, polyVertex);
output->SetVerts(verts);

At run-time, I am greeted with this message,
vtkCellArray.cxx:926 ERR| vtkCellArray (0x60464f495700): Offsets and Connectivity arrays must have the same type.
So, this is telling me that the automatic offset array creation can’t take my AffineArray as input.
I’d appreciate a clue on how to fix this. This functionality should eventually end-up in the conduit source for creating implicit pointset connectivity, as suggested to me by a developer.

2

Hi @jfavre ,

I fear this is not doable without modification in vtkCellArray …
Maybe the failing check should be changed to be only based on the vtkAbstractArray::GetDataType instead of relying on concrete class, but this needs some investigation.

@Charles_Gueunet may have more inputs.

and also maybe @spyridon97 or @Yohann_Bearzi ?

3

@jaswantp has started this MR, https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10769, which is not finished yet, because there are some performance issues to think about and funding of course. This basically allows vtkCellArray to hold any vtkDataArray subclass as offsets or connectivity arrays.

4

There are some performance issues to think about and funding of course. This basically allows vtkCellArray to hold any vtkDataArray subclass as offsets or connectivity arrays.

Clarifying some points:

  1. Only subclasses of the CRTP vtkGenericDataArray that have the ValueType equivalent to signed integer larger than 2-bytes or any unsigned integer. Floating point is obviously not sensible for connectivity/offsets.
  2. The performance issues only occur when the StorageType is none of OptimalInteger32, OptimalInteger64 which are the default unless vtkCellArray::SetData is called with an unsigned 32/64 bit integer array.
  3. @sujin will be working to get the MR in a ready-to-merge state.

I suspect perf loss is due to all that tunelling through CellStateRoutineInvoker. I haven’t profiled it. If anyone wants to squeeze more performance out of the GenericStorage type, please take a look. I might find time to profile it this week. It’s not a high priority because no existing applications will really see the performance loss.