Skip to content
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

Warning: handling deprecated packages #5986

Open
LukasvdWiel opened this issue Jul 24, 2024 · 4 comments
Open

Warning: handling deprecated packages #5986

LukasvdWiel opened this issue Jul 24, 2024 · 4 comments

Comments

@LukasvdWiel
Copy link

Hi guys 'n gals,

just trying to install Aspect here, step my step working through the dependencies. I noticed a fascinating warning when compiling Trilinos:


******** WARNING WARNING WARNING WARNING WARNING WARNING *********


  • Several Trilinos packages are scheduled for deprecation in 2025.
  • The following deprecated packages are enabled (either explicitly
  • or implicitly due to a dependency)
  • Triutils
  • ThyraEpetraExtAdapters
  • ThyraEpetraAdapters
  • ML
  • Isorropia
  • Ifpack
  • EpetraExt
  • Epetra
  • AztecOO
  • Amesos

and some of those packages (Ifpack, Epetra, Aztec00, Amesos and ML) are required when compiling Deal2, which is in turn a dependency of Aspect.

Are you sure that this beautiful house of cards does not collapse once Trilinos rips out those packages?

Have a great summer,
Lukas

@gassmoeller
Copy link
Member

Hi Lukas,
Can you provide a bit more information which version of trilinos you are using? I havent seen those messages when installing 13.2.0 or 14.4.0 (the current default in the candi installation program for deal.II). It is of course good to be aware of that, but keep in mind that we can keep using the older trilinos versions for quite some time, deal.II tends to support older trilinos version for several years. In other words, when trilinos removes these packages in 2025, we have at least until 2027 or 2028 to find alternatives for deal.II and ASPECT.

This would also be good to raise with the deal.II developers over at www.github.com/dealii/dealii as they will need to be the ones figuring out replacements or transitions (several of the ASPECT developers are also deal.II developers, but it would be good to track this issue in the deal.II repo).

You also said you are working your way through the dependencies, have you seen the official installation instructions here? Following those instructions should automate most of the process.

@LukasvdWiel
Copy link
Author

LukasvdWiel commented Jul 25, 2024

Good morning, and thank you for your time and feedback!

a very brief backgroud: we have upgraded our compute cluster from CentOS 7 (which went end of life on 30 June) to Rocky Linux 9.4, with a new kernel, new GLIBC, new compiler (GNU 14.1.0), openMPI (5.0.3), new everything.

This implied that we had to recompile everything, Aspect and its many dependencies among them.
I have regularly used candi before to install, and it tended to work very well. Rocky is not (yet) recognized by candi by default, so I force the platform with:
./candi.sh -p /trinity/opt/apps/codes/Aspect/Candi/9.5.2 --platform=deal.II-toolchain/platforms/supported/linux_cluster.platform
(normally I can run candi in parallel with -j 40, but for the clarity I have run a serial build)

The run crashes on something with the HD5 header:

[ 48%] Building CXX object source/base/CMakeFiles/object_base_debug.dir/hdf5.cc.o
In file included from /trinity/opt/apps/codes/Aspect/Candi/9.5.2/tmp/unpack/deal.II-v9.5.2/source/base/hdf5.cc:20:
/trinity/opt/apps/codes/Aspect/Candi/9.5.2/tmp/unpack/deal.II-v9.5.2/include/deal.II/base/hdf5.h: In function ‘void dealii::HDF5::internal::set_plist(hid_t&, bool)’:
/trinity/opt/apps/codes/Aspect/Candi/9.5.2/tmp/unpack/deal.II-v9.5.2/include/deal.II/base/hdf5.h:1484:30: error: ‘H5Pset_dxpl_mpio’ was not declared in this scope; did you mean ‘H5Pset_fapl_stdio’?
 1484 |           const herr_t ret = H5Pset_dxpl_mpio(plist, H5FD_MPIO_COLLECTIVE);
      |                              ^~~~~~~~~~~~~~~~
      |                              H5Pset_fapl_stdio
/trinity/opt/apps/codes/Aspect/Candi/9.5.2/tmp/unpack/deal.II-v9.5.2/include/deal.II/base/hdf5.h: In function ‘void dealii::HDF5::internal::release_plist(hid_t&, H5D_mpio_actual_io_mode_t&, uint32_t&, uint32_t&, bool, bool)’:
/trinity/opt/apps/codes/Aspect/Candi/9.5.2/tmp/unpack/deal.II-v9.5.2/include/deal.II/base/hdf5.h:1516:21: error: ‘H5Pget_mpio_actual_io_mode’ was not declared in this scope; did you mean ‘H5D_mpio_actual_io_mode_t’?
 1516 |               ret = H5Pget_mpio_actual_io_mode(plist, &io_mode);
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~
      |                     H5D_mpio_actual_io_mode_t
/trinity/opt/apps/codes/Aspect/Candi/9.5.2/tmp/unpack/deal.II-v9.5.2/include/deal.II/base/hdf5.h:1519:17: error: ‘H5Pget_mpio_no_collective_cause’ was not declared in this scope; did you mean ‘H5D_mpio_no_collective_cause_t’?
 1519 |                 H5Pget_mpio_no_collective_cause(plist,
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                 H5D_mpio_no_collective_cause_t
make[2]: *** [source/base/CMakeFiles/object_base_debug.dir/build.make:440: source/base/CMakeFiles/object_base_debug.dir/hdf5.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:4016: source/base/CMakeFiles/object_base_debug.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
Failure with exit status: 2
Exit message: There was a problem building dealii v9.5.2.

which is: deal.II-v9.5.2/include/deal.II/base/hdf5.h, line 1481:

#  ifdef DEAL_II_WITH_MPI
          plist = H5Pcreate(H5P_DATASET_XFER);
          Assert(plist >= 0, ExcInternalError());
          const herr_t ret = H5Pset_dxpl_mpio(plist, H5FD_MPIO_COLLECTIVE);
          (void)ret;
          Assert(ret >= 0, ExcInternalError());
#  else
          AssertThrow(false, ExcNotImplemented());
#  endif

I do not dare to dive into HDF5 because it is a formbidable package that I have never wrote any code for.
So to work around this I thought to compile without the candi vehicle, to be able to use a separate HDF5 (configure with MPI enabled), which seems to work well, according to what some other users are doing with it. I grabbed the most recent release of everything.
The latest Trilinos release is 15.1.1, which compiles well. I configured it with:

  cmake \
  -DTPL_ENABLE_MPI=ON \
  -DMPI_BASE_DIR=/trinity/opt/apps/development/dev2024/install \
  -DTrilinos_ENABLE_Epetra=ON \
  -DTrilinos_ENABLE_AztecOO=ON \
  -DTrilinos_ENABLE_Ifpack=ON \
  -DTrilinos_ENABLE_Amesos=ON \
  -DTrilinos_ENABLE_Techos=ON \
  -DTrilinos_ENABLE_ML=ON \
  -DCMAKE_INSTALL_PREFIX=/trinity/opt/apps/codes/Aspect/Trilinos/Trilinos-trilinos-release-15-1-1/build \
  -DCMAKE_CFLAGS=-fPIC \
  ..

The cmake flush gives this warning mentioned above, about the pckages that are no longer supported in the future.

If it ever becomes an error with a recent Trilinos, your reply assured that I can run an older Trilinos and still keep everything working, for which my thanks. :-)

Lukas

@LukasvdWiel
Copy link
Author

In reply to your remark that older Trilinos versions can be used for Deal2 -> Aspect:

That is only valid when you also use an older compiler.
Several of the Trilinos dependences (libkokkos, libteuchos, maybe more) use the variable type uint32_t, which has been removed from the C standard. While this is typically fixed in development versions, even the latest releases are still using this type. This causes compile time errors.

It can be fixed manually by including the proper header file cstint.h (which is done in the development versions of kokkos and teuchos at least), or the development versions themselves can be used, but when using modern compilers, older Trilinos versions than 15.2 (as now we are in 15.1, and that fails, I boldly assume those fixes in the dev versions will be included in the next release) will no longer be usable as they will not compile.

@LukasvdWiel
Copy link
Author

Small update: with an older compiler (gcc 11.4.0) I managed to flow straight through the candi process.
Even the hdf5 issue was not present. Had to add openblas in the candi config though, because it was not happy with a system BLAS.

At least for now I will be able to keep the people happy, here. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants