Request for a build of OpenMC 0.13.0 with HDF5 1.10.6

User Support
1

Hello everyone,

I am a grad student at UIUC working on a molten salt reactor depletion simulator called SaltProc. Specifically, I am extending SaltProc to enable depletion with OpenMC. I am using the newest version of OpenMC (0.13.0) because it has several very useful convenience functions that I’d like to preserve if possible, and since the API has already changed from 0.12.2 it makes sense to have SaltProc support the newest version out of the box.

SaltProc uses Serpent (and OpenMC soon) to deplete the fuel, runs it through reprocessing infrastructure, and iterates on this procedure until the user-specified runtime is reached. SaltProc uses the PyNE Material class to store material info and run decay calculations. The default behavior when running conda install -c conda-forge pyne is to also install OpenMC 0.12.2.

I have a PR for the first collection of changes for OpenMC ready to go (barring pep8 fixes), but one of my unit tests is failing. This is because the syntax I’m using in that unit test (Tallies.from_xml()) exists in OpenMC 0.13.0 but not 0.12.2. I tried to install OpenMC 0.13.0 in the same conda environment as PyNE and SaltProc but ran into a solver error.

Encountered problems while solving:
  - package pyne-0.7.5-moab_openmcpy39hcbc5909_0 requires hdf5 >=1.10.6,<1.10.7.0a0, but none of the providers can be installed

I opened issue 1443 in the PyNE repo to discuss this. One of the PyNE devs told me that the solver error is due to the fact that PyNE needs an older version of libgfortran, and HDF5 1.12.0 is built with a newer version, so the newest version that PyNE can use is HDF5 1.10.6. They suggested the idea of disabling the Fortran components in PyNE to allow using a newer version of HDF5.

I have been working on getting such a build up and running over the past week. I detailed this process in the same issue I linked to above. The TL;DR is that there is a memory error on the C side of things in one of the PyNE unit tests that has taken much longer to debug than I has hoped (in part due to my insistence on having a build of Python with debugging symbols in a conda environment).

I fully intend to see this issue through to the end, but I also don’t want this to hold up my work on SaltProc. Would it be possible for a dev to create a build of OpenMC 0.13.0 with HDF5 1.10.6 on conda-forge? I realize this is a very niche issue and I’m probably one of the only people it effects. I can try to make such a build myself from OpenMC source if that’s too much to ask. The easier alternative would be to just use OpenMC 0.12.2 for now, but I’m not sure how much longer that version will be supported.

2

Hi @oyardas2. Sorry to hear you’ve run into some thorny library conflicts. If I’m not mistaken, the only way I could get a conda-forge build of OpenMC to work with PyNE is to force it onto the same HDF5 version, which would essentially amount to us adding an artificial restriction on HDF5 versions which doesn’t really exist (OpenMC works fine with any version of HDF5). So, I’m not too keen on that idea. I would suggest either building OpenMC from source with the exact versions of dependencies you want and/or trying to get to the bottom of why PyNE is requiring an older HDF5 version (sounds like you’re already going down that second path).

3

Hi @paulromano, thanks for getting back to me. That’s good to hear that OpenMC works with any HDF5 version.

For OpenMC 0.12.2, the py39h0530131_1 build appears to use HDF5 1.10.6 based on the index.json file in the archive:

{
  "arch": "x86_64",
  "build": "py39h0530131_1",
  "build_number": 1,
  "depends": [
    "h5py",
    "hdf5 >=1.10.6,<1.10.7.0a0",
    "libcxx >=11.1.0",
    "lxml",
    "matplotlib-base",
    "numpy >=1.19.5,<2.0a0",
    "pandas",
    "python >=3.9,<3.10.0a0",
    "python_abi 3.9.* *_cp39",
    "scipy",
    "uncertainties"
  ],
  "license": "MIT",
  "name": "openmc",
  "platform": "osx",
  "subdir": "osx-64",
  "timestamp": 1627661514289,
  "version": "0.12.2"

This particular build of of OpenMC is the most recent one that PyNE uses. By inspection of the same files in other builds of OpenMC 0.12.2, they all use HDF5 1.12.1. Clearly this means there is some precedent for releasing a single build of OpenMC with HDF5 1.10.6 in the past. I’m not sure what the reasons for that may be, but perhaps it was just a one time thing? I’d be interested in hearing more on this point.

I am indeed working on getting to the bottom of the PyNE issues. If you’re curious about where I’m at, I’ve detailed all my progress in Issue 1443 in the PyNE repo.

Since the work scope of that effort is larger than I had hoped, for my own sanity I may just move forward with building OpenMC from source (luckily I already have some experience doing this!) so I can run my unit tests. The only downside is that I’ll need to setup some additional CI infrastructure to build OpenMC from source so I can have the SaltProc CI remain functional.

4

Some library dependencies, like HDF5, are globally pinned in conda-forge, so that pinning just happens automatically without OpenMC specifying any restriction.

1 Like
5

Ah, seems I misunderstood how OpenMC was deployed to conda forge then. I wonder what occurred on the build server that made conda pick 1.10.6 over 1.12.1.

I’ll go ahead then and build OpenMC from source for now. I’ll report back here on how that goes.

6

I’ve modified the CI workflow in SaltProc to build OpenMC from source and install it. I’m using caching so I don’t have to rebuild and reinstall OpenMC every time I update a PR. Check it out here

7

Nice use of cache dependencies , we should probably do something similar to speed up some of the OpenMC CI sometime, thanks for sharing the link