-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compile error when using dagmc from conda #739
Comments
OpenMC v0.12.1 requires DAGMC >= 3.2.0 as of this PR It looks like the version being installed conda is labeled on conda-forge as 3.2.0 but the DAGMC version header that actually gets installed indicates that it's DAGMC 3.1. From #define DAGMC_VERSION 3.1
#define DAGMC_VERSION_STRING "3.1"
#define DAGMC_INTERFACE_REVISION "$Rev$" Seems like those version numbers may have gotten out of sync? At the same time, we have a check in OpenMC v0.12.1 that should fail in configuration with an invalid DAGMC version. Not sure why it isn't getting triggered here. I'll look into that. |
This looks to be an OpenMC bug? |
Ah, yeah it looks like the DAGMC version check was accidentally removed. I'll submit a PR shortly that adds it back in so this problem is caught earlier and produces a clearer error message. |
Just opened a PR for the DAGMC check: openmc-dev/openmc#1838. Not sure what's going on with the DAGMC conda package though. |
for me looks like a conflict between the old uwuw.materiallibrary and the new one. the previous one used a |
Yes, these issues were addressed in the OpenMC PR mentioned above. But the version of DAGMC being installed with conda in the Dockerfile isn't compatible with those updates. It's too old. |
If I understand correctly DAGMC v3.2.0 should work but the latest Conda distribution is somehow getting DAGMC v3.1 when it should be getting v3.2.0 So shall we increment the build number to 1 to trigger a rebuild the Conda distribution of DAGMC 3.2.0 Or alternatively make another DAGMC release via the GitHub releases, perhaps v3.2.1 |
Yeah, that sums it up well.
I'm not as well-versed in Conda distributions as you are @shimwell, so I'm happy to go with whichever is better. Do we have an idea of how to determine why these versions are out of sync? |
Searching conda for dagmc shows 4 versions of dagmc are available
It appears that when I do
I have also tried installing a specific version using I am wondering if it might be best to release another version of dagmc with a bumped patch number as there have been a few improvements since January when 3.2.0 was released such as #722 which might help openmc check the version and looks like there were also a couple of pyne related improvements #734 #731 |
To clarify, you're getting this error whether you use |
Both |
Would bumping the build number also trigger and update by chance? Asking based on this in the In order to produce a uniquely identifiable distribution:
- If the version of a package is not being increased, please add or increase the build/number.
- If the version of a package is being increased, please remember to return the build/number back to 0. |
We are somewhat stuck waiting for a MOAB update, I think. After that, we can trickle a variety of releases through the whole stack. |
Or at least waiting for your race condition patch because none of our DAGMC tests are passing right now |
True. Just gave them another nudge! Hopefully, we'll be able to move forward soon! |
Just reporting that it looks like Moab was updated recently I'm just trying the Dockerfile again with a minor adjustment to the OpenMC version as well FROM continuumio/miniconda3:4.9.2
RUN apt-get --yes update && apt-get --yes upgrade
RUN apt-get --yes install libeigen3-dev
RUN conda install -c conda-forge dagmc
RUN git clone --single-branch --branch v0.12.2 --depth 1 https://github.com/openmc-dev/openmc.git
RUN conda install cmake
RUN conda install cython
RUN conda install h5py
RUN conda install numpy
RUN conda install pip
RUN conda install setuptools
RUN conda install hdf5
RUN apt-get install -y cmake
RUN apt-get install -y g++
RUN cd openmc && \
mkdir build && \
cd build && \
cmake -Doptimize=on \
-Ddagmc=ON \
# -DDAGMC_ROOT=/DAGMC \
-DHDF5_PREFER_PARALLEL=off .. && \
make -j && \
make -j install && \
cd openmc/ && \
pip install . |
Using the latest MOAB v5.2.1 and OpenMC v12.2 and rebuilding the Docker failed with the discovery of DAGMC v 3.1.0 by the OpenMC compiling step. This is due to the recent PR that checks the DAGMC version. I wonder if we are now at the point where the DAGMC conda install can be updated. |
For anyone looking into this I've had to update the dockerfile I've been using to test this as OpenMC has moved to version 0.12.2 and
|
Oops, didn't mean to close. |
Jus to mention I am retrying this Docker build and currently getting a I guess it might just take a while for the package to move through the in the meantime here is an updated Dockerfile pinning v0.13.0 of openmc and v3.2.1. of dagmc
which can be built with
|
🤦♂️after all that, we forgot to update the version numbers in |
Looks like that line was last written in 2018 😞 Missed it in review. Sigh. Sorry. |
It's such an annoying thing to correct, as well!! |
I'm going to circumvent the release procedure for this, if folks agree:
|
In most cases, PyNE's dependency on DAGMC is unidirectional. |
It's primarily changes in |
The DAGMC version in the conda install is now 3.2.1 🎉 However Eigan3 is still not being found I wonder if we need to include Or perhaps this is more of an issue in the way I am compiling OpenMC
|
Does OpenMC depend on eigen3 directly? It is a source code header only library that is compiled into DAGMC/MOAB where necessary, so shouldn't be necessary to use those unless the downstream code requires it directly |
OpenMC doesn't rely on Eigen3 directly, no. I think CMake is just unhappy that an include directory of DAGMC doesn't exist, whether the header files in that directory are necessary or not. As to why that directory doesn't exist, I'm not sure. |
It might be because
|
Yikes! Just explored DAGMC & MOAB on this.... there is so much header pollution! In summary, we have this hierarchy of includes in header files: It's probably true that we don't need those to be included in headers throughout, but we can let MOAB clean up their own mess and probably fix what we include from DagMC ourselves. |
Thanks for looking into this, I've just made a PR to the DAGMC conda-forge repo to include eigen in the run environment |
Just tried this now that the PR has been merged and had success! 🎉 Can you confirm @shimwell? Noting that I did have to set the |
Making use of the build 2 of the dagmc conda build for v3.2.1 in the docker file gets further than before Building the dockerfile gives an error right at the end of the openmc compile for me
@pshriwise could you let us know what you set for the hdf5 root dir so I can try that please |
I set the |
Just in case this is handy I attach the dockerfile and build log. This build log can be reporduced by running |
It looks like a compiler version mismatch?? |
looks like hdf5 is pulling in gcc-7, but you're building openmc with gcc-8, IIRC gcc-7 was an absolute horrorshow of complications, can you request hdf5 with a higher gcc version? |
Or at least, compile OpenMC with gcc-7 - but thats a pretty old compiler |
Ah thanks for all these tips I think the dockerfile is just installing old versions of a few packages from the default conda channel this command installs version 1.10.6 of hdf5 this command installs version 1.12.1 of hdf5 So I shall change the dockerfile to install from the conda-forge channel and rebuild |
Yeah - I think it becomes important to prefer conda-forge to get all the dependencies right |
Unfortunately the Dockerfile with conda-forge specified also fails |
I've been playing around with this too. I think that @gonuke's suggestion of sticking to installation from the Doing both of these things got me a successfully built OpenMC executable, but I ran into problems installing the python module due to issues finding the pthread libraries. I think I've run into that problem before with conda and can't remember how I resovled it in the past. Here's the current version of the Dockerfile I'm using:
|
Related: is there appetite for expanding OpenMC's conda-forge build to have both DAGMC and non-DAGMC options? Or would this become a separate conda-forge package? The former is definitely possible and can probably streamline things if the OpenMC team is on board. |
I am trying to build openmc with dagmc over on the conda-forge/openmc-feedstock repo conda-forge/openmc-feedstock#42 It would be great (in my option) to have dagmc as an option for the conda install of openmc |
I'm on board! Bumping this discussion thread might be a good start toward getting confirmation from others too https://openmc.discourse.group/t/conda-installation-of-openmc-with-dagmc-on/1389. |
This dockerfile builds 🎉 , happy to close this issue if others are
|
I might have celebrated too soon. While the DAGMC from conda does now allow openmc to compile it looks like something is still wrong. The resulting openmc doesn't realize it has DAGMC within See this CI where I've installed the same stack of software in the above docker image and then I've performed a openmc simulation on a DAGMC geometry but get the error message
However perhaps this is a different issue |
I totally forgot that the CMAKE lists have recently been updated for OpenMC. I've correct the cmake command to use Closing issue for now, feel free to reopen if this problem comes back Extra thanks to @pshriwise for slack help |
Describe the Bug
compile error due to dagmc pyne meta data class
To Reproduce
Build the following Dockerfile
docker build -t openmc_using_dagmc_from_conda .
Expected Behavior
I was hoping this would compile without error
Screenshots or Code Snippets
Please complete the following information regarding your system:
The text was updated successfully, but these errors were encountered: