Hi
I did a small plugin for our company last year, when I was trying to display a named block. We had a similar struggle.
Option 2 seems to be the best one for me, since it’s telling us that you have selected the “group”.
My version didn’t have the visual representation since I was struggling a bit so I removed it.
I added a small property “Ignore Compose DataSet”, An user would only be able to select a child which isn’t a multi-block dataset
Everyone seems to have understood each option.
I’m in the Option 1 camp as well. It is the common GUI design for this type of tree-based selection - and changing the meaning of commonly understood selection symbols seems like a recipe for confusion among ParaView users.
Couldn’t the fact that a node is explicitly selected be tracked internally and used to prevent this if it is a concern?
That is exactly the problem: if we track the state differently, and the GUI doesn’t show the difference, I think it’s even more confusing. Hence, if user individually checked all child nodes, which results in checking the parent node, and if we go with option 1, it really should not be any different than the user selecting the parent node.
Fully agree. I was speaking to the issue expressed by Ken:
If we are really worried about this case, then newly available tree items could be flagged as not explicitly selected. When rebuilding the tree model you could check all the children’s explicit selection status to see if the parent should be partially checked or fully checked. It’s probably more trouble than it is worth, and might not be what users expect.
The “issue” I raised is not so much an issue but just a consequence of the change. Honestly, I think this behavior will affect a sum total of 0 users and we should just let it be. As @utkarsh.ayachit said, trying to track which way the tree is selected will just create confusion and fix no real issue.
Thanks for the input, folks. Here’s the current implementation using option 1 together with an advanced list view for those few users who want more control. Note how the two tabs stay in sync as edits are made in 1 tab or the other.
If people have suggestions for the tab-names, I am all ears.
Looks good to me. A follow-up question on this – for a Python trace, if I select element_blocks in the example above and then run the generated Python script on a different input dataset with more than 2 blocks under the element_block node (e.g. block_1, block_2 and block_3), will all of them be selected here? That was a pain before and one of the problems I think you’re trying to solve, which would be a nice improvement in my mind.
yes, they will. Selecting element_blocks will extract all element-blocks even after the input dataset changes and new blocks appear.
@utkarsh.ayachit - two questions (one on-topic, one off-topic):
cheers,
/mark
The implementation is in. See vtkDataAssembly. On ParaView side, see vtkSMDataAssemblyDomain. However this is not meant for selection on readers, but rather selection for filters like extract blocks and other places like multiblock inspector. Those components still use the old composite id and I am working on it actively these days.
Can you elaborate on your use-case? Maybe we can use the same vtkDataAssembly for reader block selection too, if it’s necessary. But I’d like to understand what you’re thinking for OpenFOAM reader.
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:
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
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:
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.vtkSMDataAssemblyDomain to use assembly from an information property rather than input’s data information.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
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.
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.
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.
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
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.
I guess I should be careful for what I wished for. Either too much to understand, or simply because it is Friday 
Will try to follow/digest.