As currently as ParaView 5.12.0 the XDMF2 reader (.xmf2 extension) produces a vtkMultiBlockDataset
. Is it planned to change the reader at some point to produce a vtkPartitionedDatasetCollection
? Or will a different reader be needed? AFAIK there’s nothing about the XDMF format that explicitly requests or requires producing a MBDS
Yes, the XDMF reader and all readers that produce MBDS should change to PDC at some point. We don’t have a roadmap for when these changes will be made, but we will start planning that sometime in the near future.
Dear all,
Where are we on deprecating Multiblock datasets? Is there a timeline?
No timeline yet, but new filters and readers being created now produce Partitioned DataSet Collections.
That makes sense for new filters and readers, but when does it become acceptable to switch an existing reader (say the CGNS reader) from multiblock to PartitionedDataSetCollections? I realize that there’s no good single answer here, I’m just trying to get a sense of what the community thinks.
vtkPartitionedDataSetCollection
is fully supported now and in wide use; there is no reason to avoid switching. It is mainly a matter of funding to do the work of converting existing multiblock readers/filters to the new structure.
In addition to what David said, we need to ensure backwards compatibility for at least one release of ParaView, but probably at least a few releases. In broad strokes, that means we’ll need to:
- keep previous readers around that still produce multiblock datasets for backwards compatibility purposes (let’s call them multiblock readers)
- introduce new versions of readers that produce PDCs (let’s call them PDC readers). These could be quickly produced temporarily by wrapping the multiblock readers and inserting a filter to convert them to PDCs, and later on we would replace the guts of the filters to directly produce PDCs.
- update ParaView to use the PDC readers by default but provide a setting to use the multiblock readers for backwards compatibility
- harden support for PDCs throughout ParaView, which we continue to do
There’s some hand waving in what I wrote above, but that’s at least a high-level sketch of what I had in mind.
Hi all,
I’m looking to update the MOAB vtk/paraview plugin, so I’m looking over vtkDataAssembly and the associated changes. I totally agree that separating data representation from specification of subsetting was a necessary thing, kudos for getting to that. Unfortunately, the way I read this, the way it’s been implemented is insufficient for the general case of one represented mesh (e.g. collection of vertices, and faces (2d) and cells (3d) using those vertices) and more than one partitioning of those things over sets. I’ll describe what I mean by more than one partitioning in very concrete terms, since that gets us there faster. I have a 3d mesh that’s derived from meshing an assembly of cad bodies. I want to visualize both the subsetting represented by those cad bodies, and the subsetting you get if you partition those elements over processors. Those two different partitionings are both coverings, that is, the union of all subsets in each partition equals all the elements in the mesh.
As I understand it, a vtkDataAssembly is composed of one or more vtkDataSet members, and it’s those members that are representational. So every piece in a vtkDataAssembly is a representational set, not a subset of that set. That means that if I want to visualize both the body decomposition and processor decomposition in the same session of paraview, I have to duplicate the mesh, because the contents of each of those vtkDataAssembly instances have to be whole vtkDataSet instances. And the more different kinds of partitions you have (materials, cell dimensions, etc), the more duplication and/or sifting you have to do.
Am I reading the information about vtkDataAssembly correctly here? If not, please correct me. If I am right, then it sounds like I need something else to prevent duplicating and having to sift all this data. Maybe make data sets that are shallow copies of the representation, and some extraction filter on top of that?
In your example, the assembly of cad bodies should be vtkPartitionedDataSetCollection. Each cad body is a vtkPartitionedDataSet = it is partitioned over processors.
vtkDataAssembly is an optional hierarchy that refers to the elements in vtkPartitionedDataSetCollection (which is linear) which allows you to organize those elements in a tree structure.