Cannot rebuild petsc and libmesh on cluster during installation

[DaijunHU]

Dear All,

To update the latest moose version on my HPC cluster, which has already got mpich-3.3 and gcc-9.2, I cancelled the previous moose folder and started from curl-L the mambaforge, and it works fine.
After git clone moose, I find that I cannot update and rebuild the petsc.sh and limesh.sh, while the commands were same as what I used successfully last year.
The error told me that: Requires cmake version 3.18.1 or higher: use --download-cmake
So I tried with cmake 3.18 or using the --download-cmake,
but the error still exists and here I attach the configure.log, which I did not find out the problem.
configure.log

I attach my install command here, which was suitable for previous moose installation. Also the error.
InstallationCommand.txt
InstallError.txt

Please let me know if you have suggestions and can help me back to use moose again on the cluster.
Thank you in advance!

Daijun

[GiudGiud]

Hello

configure found the right gcc but said it was missing some features.

-- The C compiler identification is GNU 9.2.0
-- The CXX compiler identification is GNU 9.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/svu/e0751528/gcc-9.2.0/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/svu/e0751528/gcc-9.2.0/bin/g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Checking if compiler supports C11 _Thread_local
-- Checking if compiler supports C11 _Thread_local - yes
-- Checking if compiler supports needed C++17 constructs
-- Checking if compiler supports needed C++17 constructs - yes
-- Checking if compiler supports C++ make_unique
-- Checking if compiler supports C++ make_unique - no
-- Checking if compiler supports C++ unique_ptr
-- Checking if compiler supports C++ unique_ptr - no
-- Checking if compiler supports C++ filesystem
-- Checking if compiler supports C++ filesystem - no
See also "/home/svu/e0751528/projects/moose/petsc/arch-moose/externalpackages/cmake-3.20.1/CMakeFiles/CMakeOutput.log".
See also "/home/svu/e0751528/projects/moose/petsc/arch-moose/externalpackages/cmake-3.20.1/CMakeFiles/CMakeError.log".
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------gmake: Warning: File `Makefile' has modification time 0.089 s in the future
gmake: warning:  Clock skew detected.  Your build may be incomplete.
CMake Error at CMakeLists.txt:107 (message):
  The C++ compiler does not support C++11 (e.g.  std::unique_ptr).

Is there a newer cmake module you could load from your HPC platform?

never seen this before. @milljm seen this before?

Guillaume

[loganharbour]

Using a cmake module won't help; many of our dependencies including libmesh should complain of unique_ptr support doesn't exist

[loganharbour]

What you're doing here (--download-cmake) is the right thing to do.

Here's where the actual error is:

-- Checking if compiler supports C11 _Thread_local
-- Checking if compiler supports C11 _Thread_local - yes
-- Checking if compiler supports needed C++17 constructs
-- Checking if compiler supports needed C++17 constructs - yes
-- Checking if compiler supports C++ make_unique
-- Checking if compiler supports C++ make_unique - no
-- Checking if compiler supports C++ unique_ptr
-- Checking if compiler supports C++ unique_ptr - no
-- Checking if compiler supports C++ filesystem
-- Checking if compiler supports C++ filesystem - no
-- Configuring incomplete, errors occurred!
See also "/home/svu/e0751528/projects/moose/petsc/arch-moose/externalpackages/cmake-3.20.1/CMakeFiles/CMakeOutput.log".
See also "/home/svu/e0751528/projects/moose/petsc/arch-moose/externalpackages/cmake-3.20.1/CMakeFiles/CMakeError.log".
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------

<cut>

CMake Error at CMakeLists.txt:107 (message):
  The C++ compiler does not support C++11 (e.g.  std::unique_ptr).

It looks like your compiler doesn't support unique_ptr and make_unique. Are you sure that you're using the same mpich/gcc that you used previously?

[DaijunHU]

Thank you for your reply.
It is gcc-9.2.0 and mpich-3.3, I have checked with the command which gcc.
It is same as what I used previously, because I just cancelled the previous moose folder for this update, but did not remove other parts.

[milljm]

The paths present in your configure.log suggest you have several compilers in play;

Intel 2015
GCC 7.3.0
GCC 9.2.0

Please try and clean this up, as this is most likely the cause. You also mention a Mambaforge installation attempt, yet I see no mention of mambaforge paths anywhere in the log. I do see paths being set to other Python installations however:

PYTHONPATH=/app1/centos6.3/gnu/Python-3.6.4/lib/python3.6/site-packages:/app1/centos6.3/gnu/Python-3.6.4/lib/python3.6:/app1/centos6.3/gnu/SCIlibs

Warning accessing /home/svu/e0751528/miniconda/bin gives errors: [Errno 2] No such file or directory: '/home/svu/e0751528/miniconda/bin'

What troubles me, is that I see the following modules loaded when I was expecting more (gcc-9.2.0, intel).

LOADEDMODULES=cmake/3.9.3:git-2.7.0:python3.6.4

Basically, we need you to clean this up for us. How are you making these compilers available, and do you have a way to turn them off. We need to start in a sane environment before we can continue.

[DaijunHU]

Thank you for your reply.
If I do not activate those modules, the git command would not work.
Here I can attach one configure.log that without any modules loaded.
configure.log

[GiudGiud]

Hello

In this log you are using GNU 4.8.5 which is too old

-- The C compiler identification is GNU 4.8.5
-- The CXX compiler identification is GNU 4.8.5

you need to load ONE of these compilers and the associated MPI module.

On our HPC infrastructure we can look at modules with these commands, maybe they ll help you find the right compilers/mpi:

module avail
module  spider mpi

[milljm]

There is still some noise in your environment. With no modules loaded, you still have MPI and Intel Compilers:

LD_LIBRARY_PATH=/home/svu/e0751528/mpich-3.3/lib:/app1/centos6.3/gnu/gcc-4.8.2/lib64:/app1/centos6.3/gnu/mvapich2-1.9/lib:/usr/lib64/mpich-3.2/lib:/app1/centos6.3/Intel/xe_2015/composer_xe_2015.3.187/compiler/lib/intel64:/app1/centos6.3/Intel/xe_2015/composer_xe_2015.3.187/mpirt/lib/intel64:/app1/centos6.3/Intel/xe_2015/composer_xe_2015.3.187/ipp/../compiler/lib/intel64:/app1/centos6.3/Intel/xe_2015/composer_xe_2015.3.187/ipp/lib/intel64:/app1/centos6.3/Intel/xe_2015/composer_xe_2015.3.187/ipp/tools/intel64/perfsys:/app1/centos6.3/Intel/xe_2015/composer_xe_2015.3.187/compiler/lib/intel64:/app1/centos6.3/Intel/xe_2015/composer_xe_2015.3.187/mkl/lib/intel64:/app1/centos6.3/Intel/xe_2015/composer_xe_2015.3.187/tbb/lib/intel64/gcc4.4:/app1/centos6.3/Intel/xe_2015/composer_xe_2015.3.187/debugger/libipt/intel64/lib:/app1/ia32-64/iLog/opl50/bin/x86-64_rhel4.0_3.4:/app1/common/Apps/gurobi562/linux64/lib:/app1/ia32-64/meep/meep-1.0.3-parallel-icc/lib
PATH=/home/svu/e0751528/mpich-3.3/bin:/app1/ia32-64/java/current/bin:/app1/centos6.3/gnu/mvapich2-1.9/bin:/usr/lib64/mpich-3.2/bin:/usr/bin:/app1/centos6.3/Intel/xe_2015/composer_xe_2015.3.187/bin/intel64:/app1/centos6.3/Intel/xe_2015/composer_xe_2015.3.187/debugger/gdb/intel64_mic/bin:/app1/ia32-64/iLog/opl50/bin/x86-64_rhel4.0_3.4:/app1/linux/ILOG/CPLEX_Studio125/cplex/bin/x86-64_sles10_4.1:/app1/common/Apps/gurobi562/linux64/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/svu/e0751528/.dotnet/tools:/opt/pbs/bin:/app1/common/bin:/app1/linux/bin:/app1/ia32-64/g03:/app1/ia32-64/bin:/app1/ia32-64/mrbayes-3.1.2:/app1/ia32-64/phase/phase-2.0-src:/app1/ia32-64/gauss/GAUSS_9.0_Linux_amd_64:/usr/lpp/mmfs/bin:/app1/ia32-64/meep/meep-1.0.3-parallel-icc/bin:/app1/mvapich2/latest/bin:/home/svu/e0751528/bin:/app1/ia32-64/bin:/app1/common/matlab/bin:/app1/centos6.3/jdk1.8.0_05/jre/bin:/opt/pbs/bin:/home/svu/e0751528/.local/bin:/home/svu/e0751528/bin
CC=mpicc
CXX=mpicxx

I do see you have no modules loaded. Is having MVAPICH2 with Intel compilers default on this machine?
LD_LIBRARY_PATH still has a lot going on. Two MPI wrappers and an Intel compiler.

While I do see you have your custom built MPICH available before the system's, the system may still get in the way be means of being picked up by an optional configure check. Lets say 'boost', is being discovered in your Intel Composer path. Once discovered, the link line will include a path to this installation of boost. And by doing so, will include all the other libraries present at that location as well. Which is the makings for a conflict.

If you are unable to avoid loading up this Intel 2015, MVAPICH2 1.9 stack, you may have to take a drastic measure of invoking a new shell free of 'everything' and building it back up with the things you want. If you are familiar with bash, and exporting paths, etc... it is a simple process we can try and walk you through.

[DaijunHU]

Thank you all for your help. I have installed moose successfully on my cluster.
Guillaume's suggestion is helpful that maybe the GNU is too old.
I restarted from the beginning and found that there was something not included in the path correctly: I was using miniconda but now it is mambaforge after update. During my update I mixed some commands about this and thus the correct compiler is not introduced with correct locations. This may be one reason and I really appreciate all your help on this.

Best regards,
Daijun