# Support FieldData in Catalyst2
**URL:** https://discourse.paraview.org/t/support-fielddata-in-catalyst2/8763
**Category:** Development
**Tags:** proposal
**Created:** [January 12, 2022, 3:12pm UTC](https://discourse.paraview.org/t/support-fielddata-in-catalyst2/8763 "2022-01-12T15:12:28Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Francois\_Mazen](https://discourse.paraview.org/u/Francois_Mazen)
#### Post date: [January 12, 2022, 3:12pm UTC](https://discourse.paraview.org/t/support-fielddata-in-catalyst2/8763/1 "2022-01-12T15:12:29Z")
Hello Catalyst community,
I’m designing the support of VTK [field data](https://vtk.org/Wiki/VTK/Tutorials/DataStorage) 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](https://github.com/LLNL/conduit/issues/897#issuecomment-1009279427) to use the `state` node of the BluePrint mesh, which seems reasonable.
Looking at the [vtkConduitSource](https://gitlab.kitware.com/paraview/paraview/-/blob/082347269cbcbb15777f8c9e579c6d4662dcef8d/Clients/InSitu/catalyst/ParaViewCatalyst.cxx#L329), 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!
---
### Author:  [@Francois\_Mazen](https://discourse.paraview.org/u/Francois_Mazen)
#### Post date: [January 12, 2022, 3:13pm UTC](https://discourse.paraview.org/t/support-fielddata-in-catalyst2/8763/2 "2022-01-12T15:13:34Z")
@utkarsh.ayachit @ben.boeckel @coreylee ?
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [January 12, 2022, 3:23pm UTC](https://discourse.paraview.org/t/support-fielddata-in-catalyst2/8763/3 "2022-01-12T15:23:43Z")
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
```auto
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.
---
### Author:  [@Francois\_Mazen](https://discourse.paraview.org/u/Francois_Mazen)
#### Post date: [January 12, 2022, 4:52pm UTC](https://discourse.paraview.org/t/support-fielddata-in-catalyst2/8763/4 "2022-01-12T16:52:44Z")
> [@utkarsh.ayachit](#):
>
> When defining field arrays on mesh, the protocol dictates nesting them under `fields`. I’d recommend using the same for state.
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.
> [@utkarsh.ayachit](#):
>
> If you encounter duplicate filednames in the two `state`, then the channel one should override the one specified globally.
And I suppose that the duplicate field name in the mesh should also override the channel ones?
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [January 12, 2022, 5:09pm UTC](https://discourse.paraview.org/t/support-fielddata-in-catalyst2/8763/5 "2022-01-12T17:09:22Z")
> [@Francois\_Mazen](#):
>
> 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.
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.
> [@Francois\_Mazen](#):
>
> And I suppose that the duplicate field name in the mesh should also override the channel ones?
That’s correct. It’s consistent with how we’re handling time/timestep and other `state` variables.
---
### Author:  [@Francois\_Mazen](https://discourse.paraview.org/u/Francois_Mazen)
#### Post date: [February 7, 2022, 2:39pm UTC](https://discourse.paraview.org/t/support-fielddata-in-catalyst2/8763/6 "2022-02-07T14:39:13Z")
For reference, the associated merge request has been merged: [https://gitlab.kitware.com/paraview/paraview/-/merge\_requests/5454](https://gitlab.kitware.com/paraview/paraview/-/merge_requests/5454)