We had a lot of great questions during our Demonstration of a nuclear multiphysics workflow webinar on October 25, 2024 . In this post, we’ve included those questions and our responses - edited and paraphrased from the live responses. Enjoy!
If the surface mesh and volume mesh have the same conformal mesh, only tetrahedral meshes are supported for volume tallies. Any limitations from that?
For the workflow demonstrated, only tetrahedral meshes are supported for volume tallies. However, OpenMC does support tallies on other element types, though this is currently limited to a collision estimator, not track-length estimators.
What is the minimum cubit (or Trelis) version that this workflow works with? (Python API has been around for quite some time. Water-tight surface meshing has been around from ~Trelis 16.2b)
The workflow is mostly agnostic to Coreform Cubit versions for Journal file generation. For DAGMC support, compatibility began approximately in 2024.3.
Almost anything related to multiphysics between neutronics and TH/CFD in industry not just initial exploratory design for nuclear would be required to be QL-1 under NQA-1. I submit that the main hurdle for Industry using this software is the lack of V&V under NQA-1 instead of the reasons given. I believe I’ve heard that Cardinal + OpenMC + NekRS are planned to be put through an SQA process under an NQA-1 compliant program. What datasets are you using for V&V?
Ongoing efforts are underway at Argonne National Lab to bring Cardinal under NQA-1 compliance, starting with the NekRS.
Are there any plans to add adjoint capabilities to OpenMC for system kinetic parameters?
No current support for adjoint transport for continuous energy particle transport, but work is in progress to enable adjoint kinetic parameters through tally results and derivatives. The random ray solver in OpenMC now supports adjoint transport solutions.
How sensitive k-effective to the fidelity of the mesh?
The fidelity of K-effective calculations is linked to the “faceting tolerance,” which aligns the mesh and analytic surfaces. High accuracy requires very fine meshing to approximate volumes closely.
How does this workflow scale? For example, would one be able to convert ITER CSG model to CAD, and run OpenMC on an ITER DAGMC model?
While the adapter can handle complex CSG models, it hasn’t been tested on extensive cases like ITER’s detailed models yet.
Is Coreform Cubit available outside the United States?
Yes
The mesh generation is quite cumbersome for just one region. If you have adjacent regions separated by a single surface, how does the code handle possible overlaps between the meshes? Do you have to mesh each region individually or is there an automatic way to mesh large models and ensure no overlaps?
Coreform Cubit provides functionality such as “imprint and merge” to ensure single, continuous meshes across regions, preventing overlaps and ensuring shared surfaces between adjacent regions.
It’s worth noting that the tracking and tallying algorithms in OpenMC aren’t currently designed to support overlapping meshes (surface for geometry or volumetric for tallies).
It seems like the workflow depends on DAGMC. Is that separately developed, and is there a commitment to maintain compatibility between DAGMC (OpenMC, Geant4, FLUKA) and Coreform?
Paul Wilson is the project lead on DAGMC. He, myself (Patrick Shriwise) and his research team at UW – Madison do intend to maintain these capabilities.
Can you export mesh in .inp format for ANSYS from Coreform Cubit?
Yes, Cubit meshes can be exported to Abaqus though the metadata written to the mesh may require a different scheme than the one presented in this webinar.