HPC installation libraries moved (like GCC and other ones)

[RotmanC]

Hello,
I have some issues when update moose in the HPC, so I start the installation again, but I have some errors when I update and build libmesh:

libtool: warning: '/dragofs/sw/foss/0.2/software/GCCcore/11.2.0/lib64/libstdc++.la' seems to be moved
More information is enclosed in the logfile: libesh_update_rebuild.log

Here is the logfile of the petsc update and build too (I didn't find any extrange):
petsc_update_rebuild.log

I run scripts/diagnostics.sh (moose_scripts_diagnostics.log) and it seems that I'm not using Conda MOOSE packages. But since I know, in HPC it's good to install it with no environments to use already modules like GCC, MPI, right? Also, HPC install guides don't mention to install conda MOOSE environment.

How can I fix it and continue with the installation?

Thank you in advance

[GiudGiud]

Hello

So do you hit an error?
This is a warning and you can ignore it.

I think you should continue with the installation if it's just that warning.

Guillaume

[RotmanC]

Hi again.

I try to run it again, but instead of using abatchslurm.sh, I used srun to see how it works easy and quickly.

But I get this error about Gcccore dependencies...

In file included from /dragofs/sw/foss/0.2/software/GCCcore/11.2.0/include/c++/11.2.0/x86_64-pc-linux-gnu/bits/c++config.h:586,
                 from /dragofs/sw/foss/0.2/software/GCCcore/11.2.0/include/c++/11.2.0/cmath:41,
                 from ./tmp_jit_2PjqQ4.cc:2:
/dragofs/sw/foss/0.2/software/GCCcore/11.2.0/include/c++/11.2.0/x86_64-pc-linux-gnu/bits/os_defines.h:39:10: fatal error: features.h: No such file or directory
   39 | #include <features.h>

Do you know what I am doing wrong? It could be convenient to install a the moose conda environment in the HPC?

[GiudGiud]

Hello

No idea for the firewall.

For the GCCcore error when is this happening? At runtime?

If so it s likely caused by some parsed expression compilation. And you will want to make sure all the compilers are loaded in the run script, just like during installation

[RotmanC]

Hi.
I uncomment calling modules and conda and it works by srun, but it still the message:

In file included from /dragofs/sw/foss/0.2/software/GCCcore/11.2.0/include/c++/11.2.0/x86_64-pc-linux-gnu/bits/c++config.h:586,
                 from /dragofs/sw/foss/0.2/software/GCCcore/11.2.0/include/c++/11.2.0/cmath:41,
                 from ./tmp_jit_bqYLv0.cc:2:
/dragofs/sw/foss/0.2/software/GCCcore/11.2.0/include/c++/11.2.0/x86_64-pc-linux-gnu/bits/os_defines.h:39:10: fatal error: features.h: No such file or directory
   39 | #include <features.h>
      |          ^~~~~~~~~~~~
compilation terminated.
JIT compile failed.

Using sbatch I was not able to check it since there is a long wait time until it starts running.

[milljm]

Some HPC clusters use SLURM as their job scheduler. Also, many HPC clusters will configure their cluster to prevent processes from using any resources in parallel unless the process is launched using srun. The TestHarness doesn't know that it needs to do this, and thus you see failures for some tests.

The TestHarness, for all intent and purposes is a job scheduler. It walks through all the tests it is being asked to perform, and figures out how to properly manage the amount of cores you are allowing to be using at any given time (like 6 cores. e.g. -j 6). The problem is, when the TestHarness encounters a test requiring multiple cores, it will launch this test using mpiexec -n . This is where a test running on SLURM clusters will fail. As this is not the proper way to execute a binary to be run in parallel (SLURM requires that binaries be scheduled to run using srun).

But it is very problematic for a job scheduler (which the TestHarness is) to use another job scheduler (which SLURM is).

That's the long of it.

However the error you are receiving, about JIT Compilation... we might be able to solve. Can you explain how it is you ran that one test? Did you manually execute your binary (or moose_test-opt)? Can you print out all the commands you ran leading up to the failure? This will help me understand what to ask you next...

[RotmanC]

I include moose_test-opt in a batch file and I call it as: srun ./abatchslurm.sh

Now GCCcore and JIT errors don't appear. May be the HPC managers made something (I wrote them about this issue too).

The problem is that srun is configured to run only 10 minutes. For larger simulations (not test of running) have to be send through sbatch protocols.

I'm waiting to start the same simulation using the same batch file but using sbatch. I will let you know you how it works.

Thank you for your support.