Compiling AMReX Code Base with Adios2 #3382
-
|
I am attempting to compile AMReX with Adios2. We have had success compiling on an outdated AMReX version by providing the relevant Adios flags. We were able to test this with GCC 8.4.0 w/ Adios 2.4.0 and Intel 19.1.3 w/ Adios 2.7.1 We recently pulled the latest AMReX and can compile without Adios, but when we add in the Adios flags we get things like
Even when forcing CXXSTD=c++17 this still occurs. Any thoughts on how we can avoid this? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
|
So, by "Adios flags" I assume you mean that you're changing your compiler arguments when compiling with ADIOS, and presumably something more than -I and -L flags. What all are you adding? |
Beta Was this translation helpful? Give feedback.
-
|
We are following the readthedocs in this way: gives us:
Then for the amrex compile we use: When we do not include the ADIOSSCFLAGS, the amrex code base compiles fine, if we include them we get errors that seem to imply std library issues |
Beta Was this translation helpful? Give feedback.
-
|
Ah, spack. When that works, it works great, when it doesn't, it seems to do an excellent job of producing obscure problems... So, you're looking for is_same_v in std. That means that you need c++17, and the error implies that you aren't getting it. (The requirement might be new to the new version of AMReX, contributing to the problem?) I wouldn't think that any of the things in your ADIOSFLAGS variable would cause you not to get C++17 if you arranged for it otherwise (unless there's something really weird in one of those include directories that keeps the compiler from finding the right system includes). However, I'm less sure about passing the CXXSTD to make. Is that interpreted by the AMReX makefiles causing it to run C++ with the argument to yield the right C++ standard? |
Beta Was this translation helpful? Give feedback.
-
|
Yep, passing CXXSTD=c++17 to the AMReX make specifies which standard to use (and the default is c++17 so it is redundant). I am able to compile both AMReX tutorials and my source code without Adios using c++17, it only seems to break when I supply the ADIOSFLAGS. I am trying to assess if it is just how ADIOS was installed on these clusters (one academic cluster running gcc/8.4.0 with Adios 2.4.0 and another is a government cluster running intel with adios 2.7.1) or if it is how I am compiling |
Beta Was this translation helpful? Give feedback.
-
|
Upon further inspection it appears the CXXSTD=c++17 is being overwritten somehow when we add the adios flags. Supplying it as a flag CXXFLAGS="-std=c++17" does the trick! I'd be curious to understand what is happening here, but looks like problem solved. Thanks for the help! |
Beta Was this translation helpful? Give feedback.
-
|
Are you building the Makefile with CMake? If so, the Makefiles it generates are complex. The preferred solution would be to add find_package(ADIOS2) to the AMReX CMakeLists.txt file, then add adios2::cxx11_mpi as a dependency to the AMReX library. But that requires you messing with a complex CMake specification, so as long as you have a workaround maybe you don't worry... |
Beta Was this translation helpful? Give feedback.
Ah, spack. When that works, it works great, when it doesn't, it seems to do an excellent job of producing obscure problems...
So, you're looking for is_same_v in std. That means that you need c++17, and the error implies that you aren't getting it. (The requirement might be new to the new version of AMReX, contributing to the problem?) I wouldn't think that any of the things in your ADIOSFLAGS variable would cause you not to get C++17 if you arranged for it otherwise (unless there's something really weird in one of those include directories that keeps the compiler from finding the right system includes). However, I'm less sure about passing the CXXSTD to make. Is that interpreted by the A…