If you’re referring to vtkThreadedCompositeDataPipeline, this does not impact that at all and it will continue to work as before.
1 Like
This sounds practical, but is a little scary because the changes sound extensive. So long as we can be testing prior to release, I reckon we can keep things happy on the user side.
I’d think we’d shoot for spring 2021 release (v5.10). Start working on various parts now and make them active in master soon after the 5.9 release. That should give us most of the 5.10 release cycle to identify pitfalls and address issues.
Is this going to affect code like this: MultiBlockDataSet or WarpCombustor? If so there are about 30 examples that will need to be modified. Also the equivalent Python examples (if they exist).
If modifications are needed please give me some ideas. I’m happy to do the work. The VTK version macros will come in use here!
This sounds frightening, but sounds like the only way, and a very logical way, to move forward. I’m convinced we have got to move forward from the old Exodus reader. That thing is going to sink some day soon from all of the barnacles surrounding it.
Is this a big enough change in the code to justify calling this ParaView 6.0? Maybe include the update to the toolbars at the top of ParaView?
They don’t need to be updated in the first pass, but ideally should be. I can definitely help with that. Just looking the two examples, the changes should be fairly minimal, once we have the reader converted over to producing vtkPartitionedDataSetCollection – which itself is quite easy here too.
I am not sure. Let’s wait and see.
1 Like
Thanks for the offer. It is much appreciated. In my VTK build VTK_LEGACY_REMOVE is ON. So if I miss the MR, I should see it when it happens!
This is a bold move but it seems fair. Is the vtkDataAssembly designed to replace Subset Inclusion Lattice ? Can multiple vtkDataAsssembly be used over a partitioned dataset collection ?
Presumably not a large problem for our generators within OpenFOAM - they generate multiblock for topologically different items and multipiece for handling ranks, which likely map OK.
But what becomes of the .vtm format?
/mark
To some extent.
Based on our discussion earlier about selection mechanisms offered by readers, SubsetInclusionLattice for selecting which blocks should simply be removed. Readers can offer format-specific simpler selection, all of which can simply use vtkDataArraySelection instances (which should probably be renamed, since it can be used for other things than just array-selection).
The other conceptualized use-case – but not implemented yet – was to allow setting up of block parameters or selection (in case of filters like Extract Block) using the SubsetInclusionLattice. That would indeed be replaced by vtkDataAssembly.
That was indeed a use-case we were considering. Currently, it doesn’t; only one vtkDataAsssembly is supported. However, it should be possible to support that in the future – just needs a little more thinking about ramifications etc.
Indeed. Should be a trivial change.
There’s .vtpc which is replaces .vtm. However, when Multiblock Dataset is totally removed, we can make the .vtm reader produce a PartitionedDataSetCollection + DataAssembly instead (similar to the vtkDataObjectToPartitionedDataSetCollection filter under development).
Will this have any effect on VTK? Will vtkMultiBlockDataset be deprecated upstream?
Yes. However, I suspect the dataset type itself can hang out longer esp if we have 2-way conversion filters.
1 Like
A small demo of the conversion filters in action:
Here’s the current output from a CGNS file. The multiblock looks as follows:
On converting this to vtkParitionedDataSetCollection using the vtkDataObjectToPartitionedDataSetCollection filter, it looks like this:
The data-assembly captures the relationships as follows:
Thus, this for filters that care about the relationships, they have all information necessary via the DataAssembly.
Now, by applying the vtkPartitionedDataSetCollectionToMultiBlockDataSet to convert this paritioned-dataset-collection back to multiblock, we get the following:
In the case of CGNS, we can have /Base/blk1/Internal and /Base2/blk1/Internal in the same file. Thus we do not have unicity of block naming without the full path. I suspect it can be the same with vtm files.
Is it an issue ?
Very nice.
Not at all. Names in the Structure are just helpful hints and not needed to be unique. The assembly would indeed have full hierarchy. Users will be using the assembly to set color and other parameters in the Multiblock Inspector or in filters like Extract Block; so there won’t be any ambiguity.
The parts of ParaView that work with backwards compatibility that could potentially be affected are:
- Catalyst adaptors
- State files
- Python scripts
- Programmable filters (and later editions)
These are things that users work with regularly that may no longer be backwards compatible that I’m concerned about, especially since people have invested time into making these things work.
I do like the idea of improving on the multiblock dataset as there are quite a bit of issues with using it. Starting over may be what’s needed.
Indeed. I suspect it will be mix of automatic conversion and migration docs to handle backwards compatibility. By making sure this effort pays off dividends in added features and simplicity, we can hopefully ameliorate the pain.
I worry about backward compatibility for custom plugins as well, as I am extensively employing the vtkMultiBlockDataSetAlgorithm and the MultiBlock inspector in my own custom ParaView plugins (C++). It would be very convenient, after MultiBlocks get deprecated, to have clear instructions on how to switch to the new classes (the mentioned vtkPartitionedDataSet, vtkPartitionedDataSetCollection or vtkDataAssembly). If this could be provided then the transition might not be so painful then, otherwise, those who heavily use the MultiBlockDataSets, including myself, might remain “stuck” at the older ParaView versions for some time.
Note, there are filters that ParaView will use internally to convert MutliblockDataSet to the new classes for at least another version or so. So in first pass, your plugin should be not affected at all.
Indeed, an extensive guide for transitioning is a requirement for this work.
1 Like