- What you have so far is enough to rebuild the partitioned dataset collection. As far as I understand you’ll always need 2 levels for that tree. Nodes at depth 1 are partitioned datasets (PD) (with several partitions) and nodes at depth 2 are partitions (blocks) linking to the actual data.
Conceptually, given the partitioning present already in the PolyData and UnstructuredGrid formats, the blocks can already be treated as Partitioned Data Sets. This is what is reflected in this: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10355 relatively new development. The Option MergeParts turns the output into a Partitioned Data Set when deactivated. As such, those two levels are already baked into the format, are well separated into two mechanisms and conceptually correspond to the division between vtkPartitionedDataSetCollection and vtkPartitionedDataSet.
- you’ll need zero or one data assemblies which is a tree, where nodes also have a name attribute, that organize the PDs in the PD collection.
Yep, this is indeed what is represented in the diagram above by the special Assembly group. The names associated to each node of the tree are the names of the groups and blocks. This might be unclear in the representation and any suggestions for making it clearer are welcome.
I prefer to have the type spelled out just because you would lose information if you read a multiblock from a PD collection with a data assembly or similarly the node names will have to be created if you read a PD collection (with a data assembly) from a multiblock. This might be confusing. You can convert to the data you need using an additional conversion filter.
I am not sure I follow. There is a one to one correspondence between multi-block and PD collection, is there not? What information is being lost in the conversion? In the multi-block structure each block still has a name, right?