Skip to content
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

Draft
wants to merge 7 commits into
base: develop
Choose a base branch
from

Conversation

biagas
Copy link
Contributor

@biagas biagas commented Dec 17, 2024

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
  • New feature
  • [ ] Documentation update
  • [ ] Other

How 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:

  • Please follow the [style guidelines][1] of this project.
  • Please perform a self-review of your code before submitting a PR and asking others to review it.
  • Please assign reviewers (see [VisIt's PR procedures][2] for more information).

Checklist:

  • I have commented my code where applicable.~~
  • I have updated the release notes.~~
  • I have made corresponding changes to the documentation.~~
  • I have added debugging support to my changes.~~
  • I have added tests that prove my fix is effective or that my feature works.~~
  • I have confirmed new and existing unit tests pass locally with my changes.~~
  • I have added new baselines for any new tests to the repo.~~
  • I have NOT made any changes to [protocol or public interfaces][3] in an RC branch.~~

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.
@biagas
Copy link
Contributor Author

biagas commented Dec 17, 2024

@markcmiller86 could you take a look at this. Would like your input on my approach.

@markcmiller86
Copy link
Member

@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?

@biagas
Copy link
Contributor Author

biagas commented Dec 17, 2024

mpm_moving_through_partition.zip
thm_single_phase_with_fractures.zip

Open mpm_moving_through_partition/vtkOutput.pvd or
thm_single_phase_with_fractures/fractureMatrixThermalFlow_conforming.pvd

@markcmiller86
Copy link
Member

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)
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

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?

Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Some variables in vtkMultiBlockDataSet are not available
2 participants