lanl / phoebus

Phifty One Ergs Blows Up A Star
BSD 3-Clause "New" or "Revised" License
33 stars 0 forks source link

Trouble building with HDF5 on my desktop #68

Open gregsalvesen-work opened 2 years ago

gregsalvesen-work commented 2 years ago

Hi guys, I'm trying to build phoebus on my Mac Pro LANL desktop. I did this successfully with the configure options:

cmake -DPHOEBUS_ENABLE_HDF5=OFF -DPHOEBUS_ENABLE_CUDA=OFF -DPHOEBUS_ENABLE_MPI=OFF -DPHOEBUS_ENABLE_OPENMP=OFF -DCMAKE_C_COMPILER=/usr/local/Cellar/gcc/11.2.0_3/bin/gcc-11 -DCMAKE_CXX_COMPILER=/usr/local/Cellar/gcc/11.2.0_3/bin/g++-11 ..

But when I turn on the HDF5 flag and point to its installation:

cmake -DPHOEBUS_ENABLE_HDF5=ON -DHDF5_ROOT=/usr/local/Cellar/hdf5/1.12.1/bin/ -DPHOEBUS_ENABLE_CUDA=OFF -DPHOEBUS_ENABLE_MPI=OFF -DPHOEBUS_ENABLE_OPENMP=OFF -DCMAKE_C_COMPILER=/usr/local/Cellar/gcc/11.2.0_3/bin/gcc-11 -DCMAKE_CXX_COMPILER=/usr/local/Cellar/gcc/11.2.0_3/bin/g++-11 ..

the configuration is successful, but I get errors at make related to parthenon_hdf5.hpp:

bash-3.2$ make -j
Consolidate compiler generated dependencies of target kokkoscore
[ 18%] Built target kokkoscore
Consolidate compiler generated dependencies of target kokkoscontainers
[ 18%] Built target kokkoscontainers
Consolidate compiler generated dependencies of target eos_objs
Consolidate compiler generated dependencies of target parthenon
[ 25%] Built target eos_objs
[ 25%] Built target eos
[ 25%] Built target singularity-eos
[ 25%] Building CXX object parthenon/src/CMakeFiles/parthenon.dir/outputs/parthenon_hdf5.cpp.o
In file included from /Users/salvesen/phoebus/external/parthenon/src/interface/params.hpp:28,
                 from /Users/salvesen/phoebus/external/parthenon/src/interface/state_descriptor.hpp:27,
                 from /Users/salvesen/phoebus/external/parthenon/src/application_input.hpp:24,
                 from /Users/salvesen/phoebus/external/parthenon/src/driver/driver.hpp:24,
                 from /Users/salvesen/phoebus/external/parthenon/src/outputs/parthenon_hdf5.cpp:31:
/Users/salvesen/phoebus/external/parthenon/src/outputs/parthenon_hdf5.hpp: In instantiation of 'void parthenon::HDF5::HDF5WriteAttribute(const string&, size_t, const T*, hid_t) [with T = long unsigned int; std::string = std::__cxx11::basic_string<char>; size_t = long unsigned int; hid_t = long long int]':
/Users/salvesen/phoebus/external/parthenon/src/outputs/parthenon_hdf5.hpp:163:21:   required from 'void parthenon::HDF5::HDF5WriteAttribute(const string&, const std::vector<ValueType>&, hid_t) [with T = long unsigned int; std::string = std::__cxx11::basic_string<char>; hid_t = long long int]'
/Users/salvesen/phoebus/external/parthenon/src/outputs/parthenon_hdf5.cpp:1053:21:   required from 'void parthenon::PHDF5Output::WriteOutputFileImpl(parthenon::Mesh*, parthenon::ParameterInput*, parthenon::SimTime*, parthenon::SignalHandler::OutputSignal) [with bool WRITE_SINGLE_PRECISION = true]'
/Users/salvesen/phoebus/external/parthenon/src/outputs/parthenon_hdf5.cpp:339:45:   required from here
/Users/salvesen/phoebus/external/parthenon/src/outputs/parthenon_hdf5.hpp:153:26: error: no matching function for call to 'getHDF5Type(const long unsigned int*&)'
  153 |   auto type = getHDF5Type(data);
      |               ~~~~~~~~~~~^~~~~~
/Users/salvesen/phoebus/external/parthenon/src/outputs/parthenon_hdf5.hpp:102:14: note: candidate: 'hid_t parthenon::HDF5::getHDF5Type(const int64_t*)' (near match)
  102 | static hid_t getHDF5Type(const int64_t *) { return H5T_NATIVE_INT64; }
      |              ^~~~~~~~~~~
/Users/salvesen/phoebus/external/parthenon/src/outputs/parthenon_hdf5.hpp:102:14: note:   conversion of argument 1 would be ill-formed:
/Users/salvesen/phoebus/external/parthenon/src/outputs/parthenon_hdf5.hpp:153:27: error: invalid conversion from 'const long unsigned int*' to 'const int64_t*' {aka 'const long long int*'} [-fpermissive]
  153 |   auto type = getHDF5Type(data);
      |                           ^~~~
      |                           |
      |                           const long unsigned int*
/Users/salvesen/phoebus/external/parthenon/src/outputs/parthenon_hdf5.hpp:104:14: note: candidate: 'hid_t parthenon::HDF5::getHDF5Type(const uint64_t*)' (near match)
  104 | static hid_t getHDF5Type(const uint64_t *) { return H5T_NATIVE_UINT64; }
      |              ^~~~~~~~~~~
/Users/salvesen/phoebus/external/parthenon/src/outputs/parthenon_hdf5.hpp:104:14: note:   conversion of argument 1 would be ill-formed:
/Users/salvesen/phoebus/external/parthenon/src/outputs/parthenon_hdf5.hpp:153:27: error: invalid conversion from 'const long unsigned int*' to 'const uint64_t*' {aka 'const long long unsigned int*'} [-fpermissive]
  153 |   auto type = getHDF5Type(data);
      |                           ^~~~
      |                           |
      |                           const long unsigned int*
make[2]: *** [parthenon/src/CMakeFiles/parthenon.dir/outputs/parthenon_hdf5.cpp.o] Error 1
make[1]: *** [parthenon/src/CMakeFiles/parthenon.dir/all] Error 2
make: *** [all] Error 2
Yurlungur commented 2 years ago

I believe this is a mac issue in parthenon... which has to do with types. I recall we had a solution but I don't think it ever got pulled through.

brryan commented 2 years ago

This isn't an answer to this question exactly but in my experience strange issues like this are a regular occurrence when compiling code on OS X these days. My personal recommendation is to install VMware on your Mac and run Ubuntu (or some other linux distro) there. Unfortunately this doesn't usually work with GPUs, but it works well otherwise. Sorry for the inconvenience but committing to supporting OS X can cost a lot of developer hours that could go into code features. (Unless @Yurlungur is already fixing this as we speak)

Yurlungur commented 2 years ago

(Unless @Yurlungur is already fixing this as we speak)

No. I have no way to test as I don't have a working build environment on my mac. I use a VM.

pgrete commented 2 years ago

Here's the temp fix @Yurlungur was mentioning: https://github.com/lanl/parthenon/pull/613 I still wanted to rewrite this so that the correct types are checked/deduced rather than a hard ifdef switch, but as already said "cost developer hours" and didn't get that high on the priority list yet.