Support FieldData in Catalyst2

Development
1

Hello Catalyst community,

I’m designing the support of VTK field data in Catalyst2. Field data is basically metadata associated to a Data Object. The main problem is to define where the field data should be defined in the conduit nodes.

Conduit upstream advises to use the state node of the BluePrint mesh, which seems reasonable.

Looking at the vtkConduitSource, a catalyst node already supports a state node at the channel level and the child nodes (timestep/cycle/times) are already transformed to field data. As far as I understand, there is only one data node associated to a channel, hence only one blueprint mesh per channel. So adding the field data at the channel level is also a valid solution.

First question: should we put the field data nodes in the state node of the channel or in the state node of the Blueprint mesh?

Regarding the protocol, we could extend the state node by allowing user defined child nodes where the name of the node will be the data array name and the node’s values will be the data array content. We should be flexible here to allow single values (integer, double, strings…), mcArrays and string arrays.
An other approach is to add a intermediate child node field_data in the state node to avoid mixing existing state child like “timestep” or “cycle”, from the user defined nodes.

Second question: should we add and intermediate node field_data in the state node or consider all child node as field data’s arrays?

Feel free to comment and suggest any improvement. Thanks!

2

@utkarsh.ayachit @ben.boeckel @coreylee ?

3

Using state sounds reasonable. ParaView-Catalyst protocol already support global state and channel-specific state so sims can add field arrays applicable to all channels or just one channel that way.

When defining field arrays on mesh, the protocol dictates nesting them under fields. I’d recommend using the same for state. Thus, all field arrays will simply be

state:
   timestep: ...
   ...
   fields:
      fieldname0:
         ....

catalyst/state node is treated as global values for all channels that can be overridden by values in catalyst/channels/{channel-name}/state. So we can do the same for ../fields/* all arrays specified on catalyst/state are added as field data, and if any replacements (or extra ones) are provided on the channel/../state then those get added to that channel alone. If you encounter duplicate filednames in the two state, then the channel one should override the one specified globally.

4

I’m wondering if using the same keyword fields for blueprint mesh protocol and state protocol could be confusing for the users because the content syntax is different. I’ve proposed field_data to avoid this confusion.

And I suppose that the duplicate field name in the mesh should also override the channel ones?

5

I don’t think it’d be confusing. fields is being used as the term for collection of arrays. So keeping it sounds reasonable to me. field_data is a very VTK-centric term. To me, it perhaps makes sense to avoid forcing VTK-ism on the blueprint.

That’s correct. It’s consistent with how we’re handling time/timestep and other state variables.

6

For reference, the associated merge request has been merged: https://gitlab.kitware.com/paraview/paraview/-/merge_requests/5454