The purpose of this post is to propose an API in order to drive a background simulation from ParaView graphical interface (GUI). The user wants to access random simulation parameters, then tweak the parameters and send them back to the simulation engine in order to change the way the simulation is running. Ultimately, the user should be able to stop the simulation engine.
The Catalyst API already defines and implements a way to get data directly from the simulation engine and to run a specific visualization pipeline on it. A proof-of-concept from @utkarsh.ayachit proves that it is possible to send information back to the simulation engine. This experiment is based on the first version of Catalyst API through the Sensei abstraction.
In this proposal, we want to use the on-going V2 version of Catalyst to implement bidirectional API.
The Catalyst V2 API defines an abstract way to describe the data via a conduit node. For each time step, the user simply calls the
catalyst_execute method to process its data with a custom pipeline previously declared in the
To extend this behavior for bidirectional communication, the
catalyst_execute method should handle the simulation parameters that the user wants to visualize and change interactively. The user would use a dedicated key in the node dictionary like
ParaView needs a mesh to associate the parameters that the user wants to display in a pipeline. Unless it’s a limitation, the content of the
catalyst/driving_parameters key should not mention this mesh but just the parameters and their associated values.
If the conduit node can not be changed during the catalyst execution (for thread safety for instance), then we may add a dedicated method that returns the changed parameters
For the GUI description, the user has to define which parameters he/she wants to display and the way they should be displayed. The standard mechanism in ParaView for such a purpose is the XML proxy description like in Utkarsh’s sensei prototype.
Hence, the user will provide an XML file that associates graphical elements to an
vtkSteeringDataGenerator class. The XML file should also contains a dedicated XML tag
InitializePropertiesWithCatalystDrivingParameters with similar behavior to
SenseiInitializePropertiesWithMesh in order to explicitly link the driving parameter names to their GUI representations.
We can imagine two ways to pass this XML file to throught the Catalyst API: either at the compile time or at the running time.
At compile time, the XML file is embedded in the simulation build system.
At running time, the XML script is passed to Catalyst during the initialization of the process. The Catalyst V2 way is
catalyst_initialize method with a dedicated key in the argument node like
I would prefer the running time solution in order to break dependency between the parameters that the simulation engine provides and their representation in ParaView GUI. Hence changing the way the parameter are displayed and modified would not require to rebuild the simulation engine.
Of course proposed key names and method names are subject to change.
Feel free to comment this proposal.