Catalyst Bidirectional hardcoded to receive array "coords"
srizzi88 opened this issue · comments
This may be a topic for discussion more than an issue. Please let me know if I should move this somewhere else.
Our student has been struggling to figure out bidirectional with catalyst for a couple weeks. It turns out that CatalystAnalysisAdaptor expects to receive data from ParaView in an array named "coords"
SENSEI/sensei/CatalystAnalysisAdaptor.cxx
Line 154 in e0ae9a9
If the array is not named "coords" and is not a vtkPointSet, it will be ignored.
I wanted to ask if this is a design decision, or a serious limitation in the data types that we can send back from the Paraview GUI in a bidirectional communication scenario.
Hi Silvio, I think this reflects the current state of the bi-di catalyst prototype. We need to continue development of the capability to handle the data that you need access to and runtime configurability. Note, for reference Utkarsh's demo is in the oscillator testing dir, and uses the name coords. I think it's not too surprising that the name is hard coded here, but clearly that needs to change.
You've pin pointed the exact line of code that needs to be modified to accept different types of data. Go for it! But let's also set up a zoom meeting with @c-wetterer-nelson, @ghweber, @patrickoleary to discuss the next steps. The expansion of the data types that are passed, and the ability to set the names of the arrays on the fly via sensei xml are things we should be able to accomplish.
see this for conetxt #19
@srizzi88 This is a design decision, even if a bit confusing. Catalyst Bidirectional is currently designed to allow editing of point or cell arrays, specified by providing the array names (and the rest of the glue XML code) in the proxies plugin. This design was extended, for point sets, to allow editing of point coordinates. A simple way of doing that is to use this special array name "coords" to refer to point coordinates. See https://gitlab.kitware.com/paraview/paraview/-/blob/master/Remoting/Live/vtkSteeringDataGenerator.h
The only drawback of this design is a possible conflict with an actual point array in a point set called "coords". In that case, instead of being able to edit the array called "coords" you would edit the point coordinates. Note that there is no conflict for a cell array called "coords" or a dataset that is not a point set.