One thing that has come up as @Andrew works on cmb/aeva support for MED files is the notion of side and node sets, which are also present in Exodus files.
Currently, the Exodus reader creates polydata for side and node sets. This makes it hard for ParaView to allow editing of node+side sets; and hard for writers to know what is geometry is really just coincident vs what is intended to be a reference to other geometry.
I would like (eventually, not in the short term) for the MED and ExodusII readers to create vtkSelection data objects for side and node sets. There are 2 obstacles I see to doing this:
It would require extending vtkSelectionNode::SelectionField to include a new enumerant (CELL_SIDE or CELL_BOUNDARY) to deal with side sets since they typically refer to a lower-dimensional boundary of the original cell.
It might change how we want to render vtkSelection objects. (I don’t know if they are handled by mappers at all directly but suspect not… there would probably need to be changes to either mappers or representations to deal with them.)
VTK has a pretty solid mantra of only supporting non-destructive changes to data sets. That philosophy lets developers get away with copying data for side and node sets. Is the idea of referencing data from other datasets necessary if nondestructive actions are enforced?
If the issue is constructing an Exodus data set with consistent volumetric and side/node sets for subsequent use in simulation, it’s historically not really been in VTK’s purview to preprocess simulation data (there are other tools for that ), though I know that VTK’s Exodus writer has been used to perform exactly this task.
If it’s an efficiency issue (copying large subsets of a dataset vs simply referencing these subsets), I could see the need. VTK has always tried to hold data in a representation-friendy format (for better or for worse), and there would likely be a tradeoff between memory size and the speed of transfer to VBOs.
I’ve been on the periphery of a lot of conversation about different data formats and their tradeoffs (my go-to reference is usually @RobertMaynard). Could a vtk data object that references elements of other data objects be a neither-fish-nor-fowl compromise instead of using a better suited data format?
Well, even if you create a new polydata for a side set, there’s still no way to decide whether it is intended as a side set or as geometry in its own right. So, I would argue yes, referencing is still needed (or some magic strings to mark data objects as “referential” for writers — but I know someone who hates magic strings).
Nope. Right now it is about the MED file format. But since I know this moron who worked on the Exodus reader, I thought I would throw it in. You are correct that it might be better to handle this in SMTK rather than VTK, but I also find it really frustrating when VTK (or any other toolkit) doesn’t properly support the features of a file format even though it could.
What data format would you be thinking of? While VTK-m provides more flexible memory management for zero-copy access, I don’t think it has any API for denoting intentional references.
I know of at least three data formats for meshes: VTK-style (compact, analogous to VBO), hierarchical (pointer-based relations between adjacencies), and database-style (conducive to set-theoretical calculations). The first is optimized for rendering, the second is optimized for mesh generation/topology manipulation, and the third is optimized for mesh annotation.
), though I know that VTK’s Exodus writer has been used to perform exactly this task.