openmc built with dagmc?

[veeshy]

Looking to run a cad based geometry with a mesh tally over it, I installed dagmc via conda and then added -DOPENMC_USE_DAGMC=on \ to the openmc.mk file, it fails with:

[  4%] Building CXX object CMakeFiles/libopenmc.dir/src/dagmc.cpp.o
/Users/vishalpatel/mambaforge3/envs/moose/bin/mpicxx  -std=gnu++17 -DDAGMC -DFMT_LOCALE -DGIT_SHA1=\"f5bd55debd7c16560f5376cb4696b7c10abc3084\" -DGSL_THROW_ON_CONTRACT_VIOLATION -DLIBMESH -DOPENMC_MPI -DPHDF5 -DUSE_LIBPNG -Dgsl_CONFIG_ALLOWS_NONSTRICT_SPAN_COMPARISON=1 -Dgsl_CONFIG_DEFAULTS_VERSION=1 -Dlibopenmc_EXPORTS -I/Users/vishalpatel/projects/cardinal/contrib/openmc/include -I/Users/vishalpatel/projects/cardinal/build/openmc/include -isystem /Users/vishalpatel/projects/cardinal/install/include -isystem /Users/vishalpatel/mambaforge3/envs/moose -isystem /Users/vishalpatel/mambaforge3/envs/moose/include/eigen3 -isystem /Users/vishalpatel/mambaforge3/envs/moose/libmesh/include -isystem /Users/vishalpatel/mambaforge3/envs/moose/libmesh-vtk/include/vtk-9.1 -O2 -felide-constructors -Qunused-arguments -Wunused-parameter -Wunused -fopenmp -DMETHOD=opt -Werror=return-type -Werror=reorder -Woverlength-strings -DENABLE_OPENMC_COUPLING -DNEKRS_VERSION=21 -DNEKRS_SUBVERSION=1 -DGITCOMMITHASH=\"51d5bf5f2042e231d1770400c160d5623b19b4c8\" -O3 -DNDEBUG -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -fPIC -DH5Oget_info_by_idx_vers=1 -DH5O_info_t_vers=1 -fopenmp=libomp -DNDEBUG -D_THREAD_SAFE -pthread -std=c++17 -MD -MT CMakeFiles/libopenmc.dir/src/dagmc.cpp.o -MF CMakeFiles/libopenmc.dir/src/dagmc.cpp.o.d -o CMakeFiles/libopenmc.dir/src/dagmc.cpp.o -c /Users/vishalpatel/projects/cardinal/contrib/openmc/src/dagmc.cpp
/Users/vishalpatel/mambaforge3/envs/moose/include/pyne.h:6104:23: error: 'read_e_bounds' has C-linkage specified, but returns user-defined type 'std::vector<double>' which is incompatible with C [-Werror,-Wreturn-type-c-linkage]
  std::vector<double> read_e_bounds(std::string e_bounds_file);

I imagine it's some sort of build env issue considering openmc docker image can build with libmesh+dagmc. Anyone have any luck with this?

[aprilnovak]

Hi @veeshy - is the end goal to couple a DAGMC OpenMC model to MOOSE? If so, Cardinal at the moment only supports data transfers to/from cell-based OpenMC geometries.

That said, when we build Cardinal we build two executables: a Cardinal executable (cardinal-opt) and a "standalone" OpenMC executable (openmc). I think you should be able to configure Cardinal with DAGMC turned on in the OpenMC build in order to run DAGMC cases with the openmc executable (but you wouldn't be able to couple that DAGMC model to MOOSE). I could see someone doing this if they wanted to avoid having multiple OpenMC builds on their system, but otherwise there's limited utility to this.

You may already be aware of it, but there is an open-source coupling of DAGMC-based OpenMC models to MOOSE, called Aurora developed by the UKAEA.

tagging @pshriwise in case he has anything to add

[pshriwise]

One caveat: MOAB needs to be built with HDF5 support enabled. HDF5 is already a requirement for OpenMC, so hopefully that is just a matter of setting the ENABLE_HDF5 CMake option correctly.

[aprilnovak]

@veeshy I will put together the Makefile/etc. changes needed to build DAGMC with Cardinal.

In the meantime, if you want to get started with Cardinal, all of the tutorials/etc. should still apply to your use case (with a DAGMC geometry in place of a cell geometry). I'll hopefully have something soon.

[veeshy]

Awesome! Ahead of you there, I didn't do my research on what openmc was built with until it was too late though ;), I got a cell based version going (well kind of, my geometry needs the cad to be correct)

[aprilnovak]

I've got a simple MWE working that couples a DAGMC OpenMC model to MOOSE. I took the pincell DAGMC example from OpenMC and threw together a quick libMesh cube hex mesh. Here's the image of the OpenMC heat source computed on a DAGMC model, mapped to a libMesh mesh (far right):

In order to build DAGMC within Cardinal, I need a small fix to go into Pyne. After that's merged, I'll put this formally into Cardinal to support it - should be ready in a few days?

[aprilnovak]

FWIW, I was able to reproduce @veeshy's build error with MOOSE's conda environment. Seems like a minor fix arising from error checks that MOOSE enforces, but Pyne doesn't: pyne/pyne#1469