Tree widgets and check-state

Development
#21

With a linear list of mesh items, the selection is becoming absolutely crazy and if we also wish to have proper support for selecting cell-zones, we are going to need a hierarchical selection or risk have something completely unusable (partial example below). Adding zones and set names into to the selection list, will add even more.
In itself, this is not a roadblock for further development of the reader, but it would be nice to get out of the way. The next stage will probably need to entail replacing the current multiblock with a data assembly, partitioned data set etc.
Currently, the frontend to the OpenFOAM reader is vtkPOpenFOAMReader. For the parallel decomposed cases, each processor entry is treated as a separate multiblock dataset and then these are all composed together. If I use the older terminology, I think that each of these individual readers should be populating part of a multipiece dataset. This becomes even more important if we want to read the OpenFOAM collated file format, in which we lose the one-to-one correspondence of reader to data block. As the current worst case example, we would have a collated format that is partially segregated by ranks:

  • processors24_0-11
  • processors24_12-24

To be efficient, this would spin off two readers, each populating 12 pieces of the output.

After this type of reworking, I think that it would also make sense to have a closer correspondence between user selection and the output topology. It should certainly make the internals easier to follow.

For an example CHT case:

|-- bottomAir
|   |-- internalMesh
|   \-- boundary
|       |-- minX
|       |-- maxX
|       |-- minY
|       |-- minZ
|       |-- maxZ
|       |-- bottomAir_to_rightSolid
|       |-- bottomAir_to_leftSolid
|       \-- bottomAir_to_heater
|-- heater
|   |-- internalMesh
|   \-- boundary
|       |-- minY
|       |-- minZ
|       |-- maxZ
|       |-- heater_to_topAir
|       |-- heater_to_rightSolid
|       |-- heater_to_leftSolid
|       \-- heater_to_bottomAir
|-- leftSolid
|   |-- internalMesh
|   \-- boundary
|       |-- minX
|       |-- minX
|       |-- minZ
|       |-- maxZ
|       |-- leftSolid_to_bottomAir
|       |-- leftSolid_to_heater
|       \-- leftSolid_to_topAir
|-- rightSolid
|   |-- internalMesh
|   \-- boundary
|       |-- maxX
|       |-- maxX
|       |-- minZ
|       |-- maxZ
|       |-- rightSolid_to_bottomAir
|       |-- rightSolid_to_topAir
|       \-- rightSolid_to_heater
\-- topAir
    |-- internalMesh
    \-- boundary
        |-- maxY
        |-- minX
        |-- maxX
        |-- minZ
        |-- maxZ
        |-- topAir_to_rightSolid
        |-- topAir_to_heater
        \-- topAir_to_leftSolid
#22

In theory, I think we can piggy back on the DataAssembly + selectors concept to add support for block selection on readers. A few code changes will be needed in ParaView:

  1. add support for an “information property” that can return a vtkDataAssembly. Currently, we only support obtaining it as part of data information … thus suitable for filters like Extract Block where the widget is using input’s data information.
  2. Update vtkSMDataAssemblyDomain to use assembly from an information property rather than input’s data information.
#23

I know that it won’t just happen immediately, but sounds promising. I hope that after the 5.9.0 release is done and dusted, it will possible to change the OpenFOAM reader ABI as well. It looks like we may need some reworking of how times are handled, plus a different composition. When we get that far, will open a gitlab issue for communication.

Thanks,
/mark

#24

Sounds good. Also worth adding to the list is using PartitionedDataSetCollection + DataAssembly instead of multiblock dataset as the output. Actively working on getting this new dataset type working right now so more things coming in that regard.

#25

Is there a particular branch that I can monitor (to get a general idea of how it looks)? Or still only local to your machine?
You probably already thought of this, but adding a tree selector to the vtm reader (and vtm.series by extension?) could provide a smallish reference implementation for other readers to follow.

#26

Here’s my development branch. This requires VTK changes from !7568.

#27

Interesting thought. The XML readers in VTK need to be reworked, IMO. This would make sense to do for sure when we do that. The rework is not on the radar right now since it’s a big undertaking, but I definitely want to see the XML readers simplified.

Yes, I think this I can do as part the code developments needed to support use of data assembly for block selection by readers.

1 Like
#28

Hi @utkarsh.ayachit - Is there now also somewhere to look in the paraview code for implementing/using this selector? I have a MR 7602 ongoing. Would really benefit from improving the selector mechanism soon.

Cheers,
/mark

#29

here’s the MR 4694. See the new class pqDataAssemblyPropertyWidget. This is pqPropertyWidget created for properties with vtkSMDataAssemblyDomain. This domain currently only works with data-assembly provided by input’s data information (vtkPVDataInformation). This domain will need to be extended to support working with an “information-only” property instead. Next we’ll need to add a mechanism for an information-only property to fetch vtkDataAssembly to the client from the reader. Those are the items that I’ll need to put together before you can use it in your reader.

The Extract Block filter, in this MR, works with selectors so would be a good starting point to see how the selectors are described/work etc.

#30

I guess I should be careful for what I wished for. Either too much to understand, or simply because it is Friday :wink:
Will try to follow/digest.

#31

haha! Sorry! It has grown into a massive change, unfortunately. I’ve tried to organize commits logically, so it should help unravel the complexity a bit.