Exodus II Writer

[EdwardPalmer99]

Brief

• This PR adds ExodusII mesh outputs.
• The writer can handle multiple element types (one type per element block).
• Added writer unit tests (some are commented-out until the reader is updated).
• The following element types are supported:

First-Order Element Types

• Hex8
• Tet4
• Wedge6
• Pyramid5

Second-Order Element Types

• Hex27
• Tet10
• Wedge18
• Pyramid14

Caveats

• Cannot mix first- and second-order element types
• Wedge18/Pyramid14 are not supported by the current ExodusII reader
• Limited file options (will extend in future)
• Issues with Tet node ordering if refine=1 (set to zero to avoid issues)
• No support for multiple timesteps
• Assumptions about element order are made

Future Work

• Once Extend ReadCubit to Add Support For First/Second Order Pyramid and Wedge Elements and Mixed Meshes #4178 is merged, the commented-out mixed mesh and wedge/pyramid tests should be uncommented. These have been tested.
• It would make sense to move the ReadCubit code into the same file in a future PR and create a reader class similar to the ExodusIIWriter.
• Add option to write-out coordinates in blob format (xyz, xyz, xyz) rather than large file format (xxx, yyy, zzz). The reader should be updated to handle reading-in files written using the blob format.

PR	Author	Editor	Reviewers	Assignment	Approval	Merge
#4208	@EdwardPalmer99	@tzanio	@mlstowell + @bslazarov + @jandrej	4/7/24	⌛due 4/21/24	⌛due 4/28/24

PR Checklist

• Code builds.
• Code passes make style.
• Update CHANGELOG:
  • Is this a new feature users need to be aware of? New or updated example or miniapp?
  • Does it make sense to create a new section in the CHANGELOG to group with other related features?
• Update INSTALL:
  • Had a new optional library been added? If so, what range of versions of this library are required? (Make sure the external library is compatible with our BSD license, e.g. it is not licensed under GPL!)
  • Have the version ranges for any required or optional libraries changed?
  • Does make or cmake have a new target?
  • Did the requirements or the installation process change? (rare)
• Update continuous integration server configurations if necessary (e.g. with new version requirements for each of MFEM's dependencies)
  • .github
  • .appveyor.yml
• Update .gitignore:
  • Check if make distclean; git status shows any files that were generated from the source by the project (not an IDE) but we don't want to track in the repository.
  • Add new patterns (just for the new files above) and re-run the above test.
• New examples:
  • All sample runs at the top of the example source file work.
  • Update examples/makefile:
    • Add the example code to the appropriate SEQ_EXAMPLES and PAR_EXAMPLES variables.
    • Add any files generated by it to the clean target.
    • Add the example binary and any files generated by it to the top-level .gitignore file.
  • Update examples/CMakeLists.txt:
    • Add the example code to the ALL_EXE_SRCS variable.
    • Make sure THIS_TEST_OPTIONS is set correctly for the new example.
  • List the new example in doc/CodeDocumentation.dox.
  • If new examples directory (e.g.examples/pumi), list it in doc/CodeDocumentation.conf.in
  • Companion pull request for documentation in mfem/web repo:
    • Update or add example-specific documentation, see e.g. the src/examples.md.
    • Add the description, labels and screenshots in src/examples.md and src/img.
    • In examples.md, list the example under the appropriate categories, add new categories if necessary.
    • Add a short description of the example in the "Extensive Examples" section of features.md.
• New miniapps:
  • All sample runs at the top of the miniapp source file work.
  • Update top-level makefile and makefile in corresponding miniapp directory.
  • Add the miniapp binary and any files generated by it to the top-level .gitignore file.
  • Update CMake build system:
    • Update the CMakeLists.txt file in the miniapps directory, if the new miniapp is in a new directory.
    • Add/update the CMakeLists.txt file in the new miniapp directory.
    • Consider adding a new test for the new miniapp.
  • List the new miniapp in doc/CodeDocumentation.dox
  • If new miniapps directory (e.g.miniapps/nurbs), add it to MINIAPP_SUBDIRS in the makefile.
  • If new miniapps directory (e.g.miniapps/nurbs), list it in doc/CodeDocumentation.conf.in
  • Companion pull request for documentation in mfem/web repo:
    • Update or add miniapp-specific documentation, see e.g. the src/meshing.md and src/electromagnetics.md files.
    • Add the description, labels and screenshots in src/examples.md and src/img.
    • The miniapps go at the end of the page, and are usually listed only under a specific "Application (PDE)" category.
    • Add a short description of the miniapp in the "Extensive Examples" section of features.md.
• New capability:
  • All new public, protected, and private classes, methods, data members, and functions have full Doxygen-style documentation in source comments. Documentation should include descriptions of member data, function arguments and return values, template parameters, and prerequisites for calling new functions.
  • Pointer arguments and return values must specify whether ownership is being transferred or lent with the call.
  • Any new functions should include descriptions of their intended use e.g. for internal use only, user-facing, etc., along with references to example code whenever possible/appropriate.
  • Consider adding new sample runs in existing examples to highlight the new capability.
  • Consider saving cool simulation pictures with the new capability in the Confluence gallery (LLNL only) or submitting them, via pull request, to the gallery section of the mfem/web repo.
  • If this is a major new feature, consider mentioning it in the short summary inside README (rare).
  • List major new classes in doc/CodeDocumentation.dox (rare).
• Update this checklist, if the new pull request affects it.
• Run make unittest to make sure all unit tests pass.
• Run the tests in tests/scripts.
• (LLNL only) After merging:
  • Update internal tests to include the new features.

[tzanio]

Thanks @EdwardPalmer99!

[tzanio]

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

[mlstowell]

Hi, @EdwardPalmer99,
Thanks for submitting this. It will be a good addition to MFEM. I have a few notes that could make this more MFEM-like. I'll comment in the files.
Best wishes,
Mark

[mlstowell]

We are reluctant to place variables directly into the mfem namespace. Even when they have such specific names as these. I think we would most often define these as static variables within something like the ExodusIIWriter class. If you prefer they could probably be placed within a separate utility class. Other possibilities exist. If you have a strong inclination towards a particular solution we can certainly discuss options.

[EdwardPalmer99]

Okay, sure. How about plonking them into an "ExodusIILabels" namespace? I think this is a better solution than putting them into a utility class.

[mlstowell]

As long as that namespace is inside the mfem namespace I think that would be fine.

[pazner]

Perhaps these mesh files (which add up to about 0.5 MB) should be moved to the mfem/data repository. The unit tests can then be tagged with the tag [MFEMData], so that they will only be run if the unit test executable is passed the --data command line argument.

[mlstowell]

typo: mehs

[mlstowell]

I suggest we change this so that the attempt to write an output file stops but program execution can continue. We could print a warning message stating either that mixed meshes are not yet supported or that Exodus II meshes do not support mixed element types. Whichever is more accurate.

While we're on this topic: if mixed meshes are supported but mixed blocks are not then I would like to see an outline of how we might improve such support in the future. Might it be as simple as pre-processing the mesh and dividing regions with a common attribute number into multiple blocks based on element type?

[mlstowell]

We need to be a little more discerning here. At the very least we should confirm that the Nodes defined in the mesh do indeed correspond to a 2nd order H1 space (because that would seem to be the assumption made later on). We can then exit gracefully with a warning message if printing this particular type of mesh is not supported.

In the future we can perhaps address issues such as Nodes based on L2 spaces. We could even project higher order Nodes to 2nd order nodes as long as we print a warning message. These improvements do not need to be handled at this time but we should be clear about the limitations of the current implementation.

[mlstowell]

I'm not certain but I believe this call to at may be failing on interior surfaces such as those found in miniapps/multidomain/multidomain-hex.mesh. Some would argue that "boudary" faces should never exist within the interior of a mesh but MFEM meshes do support this. Unfortunately this means that this writer must determine how best to handle such things. Does the Exodus II format support interior "boundary" faces? Does it store such things in a different manner? At the very least the current implementation of this writer should recognize these "interior" boundary faces and skip them if necessary (and issue a warning message to that effect).