-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for GEOS data to vtk reader #20141
base: develop
Are you sure you want to change the base?
Conversation
Each .vtm file is considered as one mesh. Blocks with 'Region' in the name that are Parent to 'Dataset' Blocks are considered groups. Variables defined in the underlying .vtu files are tracked for which blocks they belong to, since they may not be defined in every group. GetMesh and GetVar calls check the validity of the mesh/variable for a given block and return nullptr when not considered valid.
@markcmiller86 could you take a look at this. Would like your input on my approach. |
Sure thing. Do we have data I can play with? |
mpm_moving_through_partition.zip Open mpm_moving_through_partition/vtkOutput.pvd or |
Its going to be a minute because I was in middle of build of develop for a tiny enhancement there. |
|
||
|
||
bool | ||
CheckIfGEOS(const string &rootFile) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I haven't seen actual file I/O being done in the XXXCommonPluginInfo.C
routines before. I am not saying that is bad. Its just different than how I've seen this kind of thing done in say NETCDF or PDB uber plugins.
Doing it here in the CommonPluginInfo routines might be better, especially for ST
type databases that would otherwise wind up doing that kind of work for every time state in the database being opened.
One thing. Must you read the whole xml file here? I mean, can you get away with reading just a header or some number of initial lines? Not a big issue but this is I/O work VisIt will do to simply decide if this plugin is the right plugin to use on the file too. So, if the XML file is huge and this plugin is ahead of others it might try when guessing the plugin from file extension, that could reprsent a lot of work as part of VisIt's file extension-to-plugin guessing process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only plugins supporting .vtm and .pvd is the VTK plugin, so I think we are okay there.
Could possibly change how the information from the .xml files is garnered, but would have to use something other than vtkXMLDataParser. If you think this could be problematic, I can look into other ways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so I would NOT worry about this at the moment. However, it might be good to add a teeny bit of logic there that generates a message on debug1
when the XML file is larger than maybe the original design here had anticipated. So, maybe stat
the file before reading it or if the XML lib you are using gives you a way to ask about file's size in bytes and then maybe issue a remark to debug1
if file size is substantially larger than original design assumes. Maybe set the threshold at 100Kb or 1Mb.
I dunno...maybe I am being too speculative. But, the database plugin sequence is complicated and can fail or bog down for a whole slew of subtle reasons.
src/config-site/WIN-5525018.cmake
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I built and looked at the data and I like the way blocks subsetting works. I happened to have a mesh plot up but then plotted a variable defined on only some of the blocks and I think it looks fine....you wind up with the whole mesh (plotted as just lines) and the PC plot of the variable on just the two blocks it was defined on.
Was there anything else in particular you wanted me to take a look at?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking a look, much appreciated. Nothing else at the moment.
Description
Resolves #17276
Adds support for GEOS flavored .pvd (root file) and .vtm vtk files.
Determination of GEOS flavor is done by reading the first .vtm file searching for Blocks with name attributes of either:
CellElementRegion, SurfaceElementRegion, ParticleRegion or WellElementRegion.
An MTMD file format is instantiated for this flavor, with HasInvariantMetaData and HasInvarientSIL set to false and HasVarsDefinedOnSubMeshes set to true.
The avtGEOSFileReader parses the .vtm, grouping by 'Region' elements. The first .vtu data set file in each group is read for constituent variable arrays, which are tracked so that the reader knows whether a given block has the requested variables during a GetMesh or GetVar call.
I added helper functions to avtVTKFileReader for setting MetaData to aid in this work.
Type of change
[ ] Bug fix[ ] Documentation update[ ] OtherHow Has This Been Tested?
I have opened the latest example datasets given in the ticket with success, plotting variables defined on all blocks as well as those only defined on some, traversing back and forth and through all time states.
The SIL subset selection works with the groups and blocks.
Reminders:
Checklist: