I tried the new ExtractBlock filter and it functions just as expected (no more changing parts between timestates!) but I have a few comments/concerns.
-
From what I see the only way to directly set the xpath-style selectors is through Python.
For some reason I was expecting to have some kind of text input in the ExtractBlock properties. Was this ever under consideration? I think it would add much value for non-power users.
-
It appears that blocks starting with a number need an underscore prefix. Can this requirement be removed? It’s going to be one of those things that I end up telling every user at least once and they’re all going to say “Ahhhh. Why? That’s stupid” 
Example: The following selectors correspond the the block selections in the GUI:
['/Root/Solid/_1_soil_tube', '/Root/Solid/_3_HE']
-
What is up with the drop-down menu below the Blocks structure? Under what circumstances can I except this menu to contain multiple options and how does it affect the selection process?
-
I can select all the Solid blocks in the above image using ['/Root/Solid/*'] but I cannot select parts 6 and 7 using ['/Root/Solid/*block']
And using ['/Root/*/_2_soil'] selects only the block under Solid.
Using simple wildcards (I suppose regex is too complicated) would add a ton of value, at my company at least. We work with large assemblies and generally use pretty tight naming schemes (the example above is not a good representation of our typical model).
-
Is there a way to use the shown top-level block name instead of (or ideally in addition to) 'Root'? I expect users are going to try ['/vtkMultiBlockDataSet/Solid'].
Try hitting the “gear” to enter advanced view for the panel. You’ll see the Selectors tab.
It appears that blocks starting with a number need an underscore prefix.
Internal representation uses XML. That requires the block names are valid XML node names. That requires changes to such block names when they are not valid XML node names. Multiple options:
- remove the number prefixes from the blocks.
- use
@label, ex. //*[@label="1_soil_tube"]
What is up with the drop-down menu below the Blocks structure?
For vtkPartitionedDataSetCollection, we support a separate assembly. If you open can.ex2 from ParaViewData for example:
Using simple wildcards (I suppose regex is too complicated) would add a ton of value, at my company at least.
Here’s info about supported XPath.
Is there a way to use the shown top-level block name instead of (or ideally in addition to) 'Root' ?
Should be fixable. Please report an issue.
Ah, I don’t how I missed that. I should know better.
Thanks, my understanding of XPath was a little (maybe very) off.
So I see that I have to use the expression //*[contains(@label,'2_soil')] to select both blocks that start with 2_soil because of the [1] duplicate identifier that is automatically added.
Is there another XML attribute that holds the literal block/grid name as defined in the .xmf file if the data source is the XDMF format?
Relevant portion of my .xmf file:
<Grid GridType="Collection" CollectionType="Spatial" Name="SPH">
<Grid GridType="Uniform" Name="2_soil">
<Attribute Name="PartID" Center="Grid" AttributeType="Scalar">
<DataItem Format="XML" Dimensions="1" DataType="Int">2</DataItem>
And regardless of the answer to that, I’m thinking I might want to build a custom filter that simplifies the selector syntax for the user. Would basically be a wrapper around this new ExtractBlocks filter that translates my own selector language to the required XPath one.
Would this be possible? Can I access the internal XML representations and ExtractBlock operations on the VTK side? I know I could just iterate through the MBDS itself and look at each block name but I’d love to take advantage of the XPath capabilities.
In theory, yes. But would need some work. Ideally, the reader starts producing vtkPartitionedDataSetCollection instead of vtkMultiBlockDataSet. Then it can attach arbitrary assembly to the dataset. That assembly should be able to represent the XMF structure.
Can I access the internal XML representations and ExtractBlock operations on the VTK side?
See vtkExtractBlockUsingDataAssembly.
