in paraview 5.4.1 it was possible to do a selection of base and family to read from CGNS file from python (It was an “AND” operator between base and family).
Code looked like this: myreader = CGNSSeriesReader() myreader.FileNames = ['post_aircraft.cgns',] myreader.BaseStatus.DeselectAll() myreader.BaseStatus = ["Base#2"] # Select second base myreader.FamilyStatus.DeselectAll() myreader.FamilyStatus = ["Wing"] # Only select Wing family zones in Base#2 not in Base#1 ...
How can we do the same thing with recent Paraview 5.7 from python ?
Answer to myself
Code now looks like this: myreader = CGNSSeriesReader() myreader.FileNames = ['post_aircraft.cgns',] myreader.DeselectAllBases() myreader.DeselectAllFamilies() myreader.SelectFamily("Wing") # Select Wing family zones in all bases (Base#2 and Base#1) myreader.DeselectBase("Base#1") # Unselect Base#1 …`
This is slow. This is not pythonic : you can not pass a python list of family names to be selected like before.
The AND operator is not done between Base#2 and Family. You need to unselect Base#1 instead of selecting Base#2 (not natural for user).
This issue stems from my limited understanding of how users would prefer to select blocks to read. This was my attempt at making it consistent with other readers, viz. Exodus, Xdmf, to let user pick blocks to read using any and all relationships available. We had added that functionality to these readers in the days where ParaView didn’t have things like Multiblock Inspector [1] which allows users to set visibility and other display parameters for blocks. That being the case, I am tempted to say that this elaborate mechanism to choose blocks to read is an overkill. We should let readers offer subsetting blocks to read as is most natural for the reader (in CGNS’s case, revert back to the 5.4 behavior). The block relationships still would need to be described to use to set parameters for filters like Extract Block or Multiblock Inspector, but that is probably a separate thread.
[1] the Multiblock Inspector only shows the parent-child relationships defined by the data hierarchy and hence it not flexible enough to show all available relationships, but that is expected to change in future.
I think having selection consistent between readers is hard but ParaView is going in the right direction. It just need to get some adaptable framework that let readers customize how they do selection based on database like request (with OR/AND operand) and also the amount of data being read.
I really like the idea of propagating the block relationships to extract filter.
Actually, this is exactly what I have been doing with CGNS data in PV5.4 . I use two filters to extract data:
first one ExtractBlockInFamily just get the family information key for each block and if it matches the families requested by the user, the block is added in a multiblock dataset under a Block named by its family. Mutiblock inspector ouput looks like this: Root [ Family1 [ block3444; block3560 ...]; Family2 [ block0001; block0045] ].
Since it relies on vtkInformationKey local to the block it works nicely in parallel or multiprocess environment.
second one ExtractBlockByName is used when people send me CGNS files without family. Here I just parse block name to known if they should be extracted. Two behavior are possible: either it matches a regex from the user or the user provide a json file with the wanted output layout and the matching is done against the json data leaf (Thus it can recreate families that where missing).
@MicK7, mind reporting an issue? For 5.9, I want to get rid of all the unnecessary SIL changes and bring back the older/simpler family/base selection API.
For 5.10, we should then plan to change the output to be a PartitionedDataSetCollection, but that can wait till reset of the PartitionedDataSetCollection support related changes are done.