Intended Workflow to Generate Superimposed MOAB meshes

[jbtompkins]

Hello,

I want to run a neutron transport model using native OpenMC geometry and then run flux tallies on an overlayed unstructured mesh similar to this Example with the main differences being I only want flux tallies and the geometry of the flux mesh I want is a reactor pressure vessel (RPV) rather than LWR pins. I already have the reactor model I want to use, but I am having trouble with the mesh bit.

In the example linked above, it says that the file visualized is generated by Trelis, which I can see being no problem because the bit that is visualized is the Exodus file. However, the file that is run is the MOAB .h5m file. My organization uses Coreform Cubit for meshing, and I do not believe there is a way for Coreform Cubit to natively export MOAB files. I would be happy to try to use libmesh as the OpenMC mesh library, but it sounds like it does not have support for flux tallies.

I take this to mean I need to convert my Exodus (.e) mesh to MOAB (.h5m).

A bit about the mesh:

Executive Exodus summary:
  Number of dimensions     = 3
  Number of element blocks = 12
  Number of sidesets       = 0
  Number of nodesets       = 0
  Number of bc sets        = 1
  Number of elements       = 10368
  Number of nodes          = 15558

Element type is HEX8. I bring this up because when we tried to run the exodus file with MOAB set as the mesh library we got this error back:

RuntimeError: --------------------- Error Message ------------------------------------ [0]MOAB ERROR: ../inputs/openmc_RPV_mesh.e: File is not HDF5! [0]MOAB ERROR: set_up_read() line 438 in src/io/ReadHDF5.cpp [0]MOAB ERROR: --------------------- Error Message ------------------------------------ [0]MOAB ERROR: NULL file handle.! [0]MOAB ERROR: is_error() line 125 in src/io/ReadHDF5.hpp WARNING: Non-tetrahedral elements found in unstructured mesh file: ../inputs/openmc_RPV_mesh.e *** stack smashing detected ***: terminated [castle-bravo:2665942] *** Process received signal *** [castle-bravo:2665942] Signal: Aborted (6) [castle-bravo:2665942] Signal code: (-6) [castle-bravo:2665942] *** Process received signal *** [castle-bravo:2665942] Signal: Segmentation fault (11) [castle-bravo:2665942] Signal code: (128) [castle-bravo:2665942] Failing at address: (nil)

Which I take to mean there are two problems:

1. This isn’t a .H5M file (understandable)
2. The mesh may be able to be read in some limited capacity, but that it didn’t like that I was using non-tet elements. This is the more interesting of the errors to me. The few examples I’ve seen of the unstructured mesh capability being used in OpenMC have all been TET meshes, so I guess one question I have would be can HEX elements be used with OpenMC’s unstructured mesh tally feature?

I’ve only been looking into this since yesterday, but it seems that if I wanted to convert between mesh files the first place most start is using meshio. I have installed it via conda and their documentation makes conversion seem as easy as the one liner: meshio convert input.e output.h5m However, when I do this I get the following warnings:

It does generate a .h5m file though. When trying to run it in OpenMC though we get this error:

Creating state point statepoint.60.h5...
 Writing unstructured mesh tally_5.60.vtk...
[0]MOAB ERROR: --------------------- Error Message ------------------------------------
[0]MOAB ERROR: Nothing to write!
[0]MOAB ERROR: gather_mesh() line 191 in src/io/WriteVtk.cpp
Writer with name VTK for file tally_5.60.vtk using extension vtk (file type "(null)") was unsuccessful
Using default writer WriteHDF5Parallel for file tally_5.60.vtk

I wanted to be thorough in my initial question for visibility into my problem, but to summarize my questions:

1. What kind of meshes are currently supported within OpenMC’s unstructured mesh functionality? I’m interested in element type, file type, and features available for each (if different).
2. What is the intended workflow for unstructured mesh generation for use with OpenMC, and is it different from the most low-effort/fastest setup workflow? What would the differences be between them?

Any help would be greatly appreciated!

[Shimwell]

Hi Jbtompkins

Welcome to the community.

Tet elements are supported by the unstructured mesh feature. This is the only element type currently supported by the DAGMC unstructured mesh. However OpenMC also has a libmesh option that supports other element types. For tet mesh here is some info

Two file formats are supported
Exodus files can be used which requires OpenMC to be compiled with Libmesh. Cubit can export these but also exodus files can be made in other meshing software as well. Here is a cubit command.
cubit.cmd('export mesh “tet_mesh.exo”)

H5m files can also be used, sometime this is referred to as a DAGMC unstructured mesh. These require OpenMC to be compiled with MOAB. OpenMC with MOAB is also available through mamba install. There are two way to get from Cubit to h5m unstructured meshes. One is to export an Abaqus file and convert, but this is quite slow. The main option for h5m is to export a .cub file from cubit and convert.
Cubit command
cubit.cmd(‘save as “tet_mesh.cub” overwrite’)
Terminal command to convert (Moab command)
mbconvert tet_mesh.cub tet_mesh.h5m

Best of luck

[jbtompkins]

Thanks for you response,

I am glad to get confirmation that only tet elements are supported. I was able to successfully convert my mesh using the mbconvert tet_mesh.cub tet_mesh.h5m command though mbconvert complained a bit:

$ mbconvert openmc_RPV_mesh.cub openmc_RPV_mesh.h5m
Element ids are not contiguous!
Read "openmc_RPV_mesh.cub"
Wrote "openmc_RPV_mesh.h5m"

I was curious as to whether the non-contiguous elements would be a problem, but was able to tally on the resultant mesh.

That being said, we did have some interesting findings before you had responded. First, we were actually able to run tallies on the exodus mesh file using the MOAB library:

I got an error from MOAB that said my file was not an H5M, but then it seemed to just continue on with the tally. With the ability to now convert to H5M from the same cubit geometry that generated my exodus file, I wanted to see if there was functionally any difference between the two. This is certainly not the most robust method to diff the two, but pulling up a side by side of the vtk files (one tallying on the exodus mesh and one tallying on the MOAB mesh) plotting flux, I get what looks to be two identical results:

My question now would be whether there would be any perceived adverse behaviors (other than the Error from MOAB about the mesh file type) from me just using exodus meshes with the MOAB mesh library for tallies?

[Shimwell]

Nice screen shots.

I can’t think of any adverse behaviors and I wouldn’t worry about the non-contiguous warning but @pshriwise is the expert for these sorts of questions. It might also be worth mentioning this on the DAGMC forum https://groups.google.com/g/dagmc-users.

[pshriwise]

@jbtompkins welcome to the forum!

I’m feeling foolish because we talked earlier this week in slack and I didn’t identify the easiest path, which is to use a build of MOAB with support for netcdf and use your exodus mesh instead of converting it. This is what we do for our unstructured mesh unit tests in fact. I’m glad you figured it out though!

The error message from MOAB about the input format isn’t cause for concern. It always attempts to read that format first and complains of it can’t.

The non-contiguous IDs aren’t an issue either really. It’s just a heads up in case your application relies on that.

[April]

FWIW I believe the mesh tally works with any element type that libMesh supports, not just tets. I use it frequently with hex elements. Here’s an OpenMC mesh tally with both hexahedral + prism elements.

[jbtompkins]

When I attempt to use hex elements, I get an error when trying to write to the mesh. Are you using OpenMC with the MOAB mesh library or libmesh?

[April]

Oh good point - I only use the libMesh tallies. I forgot that MOAB could have other restrictions on element type.