Installing OpenFOAM on a cluster

I’m working on a cluster running on CentOS 6. When compiling OpenFOAM-v2112 (not the preCICE adapter yet) I get some error that I can’t trace back to anything.

I followed the instructions from here. And they worked on my personal setup.

With versions of modules:

  • gcc/7.3.0
  • openmpi/64/1.10.4/gcc/5.4.0

And compiled by me:

  • boost_1.77.0
  • cmake 3.21.3

One possible problem I could imagine is, that openmpi is compiled with a different version of gcc. Can this be a problem? Otherwise I have to recompile boost with the older version of gcc.

I appended the output of the execution of ./Allwmake. Can you make sense of the output? What other information do you need to understand my issue?

Output of foamSystemCheck

Checking basic system...
Shell:       bash
Host:        lead
OS:          Linux version 2.6.32-358.6.1.el6.x86_64

System check: PASS
Can continue to OpenFOAM installation.

Should I instead of v2112 use an older Version of OpenFOAM?

I guess the easiest for you would be to use Spack: building · Wiki · Development / openfoam · GitLab You just need to install Spack and then do spack install openfoam.

I cannot see any such output here.

I think that OpenFOAM v2112 did, indeed, upgrade a few dependencies, which may have triggered such issues. The OpenFOAM adapter works also with older versions, so if that is something that would help you, you can indeed try it!

You did not append the output from Allwmake, so it’s difficult to say, but:

this is going to cause problems.

The two modules you load are not compatible. While I also use the gcc7 toolchain for most of my work, OpenFOAM should compile nicely with gcc 4.8 or 5.4 (which seems to be the one your openmpi is compiled with).

A cluster that’s running CentOS 6 is most likely a hot mess with respect to modules and various gcc versions being used to compile them.

So unless you have an openmpi/*/7.3.0 module, I’d recompile everything (incl. OpenFOAM with gcc 5.4.

1 Like

I did try this in the past, and while it worked nicely on half the cluster, it didn’t on the other. Was a bit of a lottery which node your job ended up on. Couldn’t find what the issue was. All nodes were same architecture, kernel and stack.The same cluster run the same compiled versions of everything just nicely.

Thank you both for your answers, sorry I forgot the log, here is it:
log-Allwmake.txt (1.5 MB)

I tried installing Spack, but it only worked with one specific python anaconda version and there spack failed installing openmpi.

Then my next best try would be to recomile everything again with gcc 5.4.

Another thing I noticed:

The errors at the beginning: “wait: -n: invalid option” should not show up.

Which shell are you using? The Allwmake script uses #!/bin/sh, which can be an alias to the POSIX variant of bash (as it is here on my CentOS 7 cluster - a simply link to bash) or (in some cases causing problems with scripts) a mini-shell, which may behave differently.

bash’s “wait” builtin has the -n option.

If /bin/sh is something different to bash, it may be worth forcing the script to execute using the full bash shell, by changing the shebang to #!/bin/bash

I just want to add that there is a good chance that the bash on Cent OS is simply too old and the -n option of wait is simply missing. A quick search (on Stackoverflow) indicates that the option was introduced in bash 4.3 which was introduced in 2014. I am not sure if this is a serious issue though.

I would also assume that the (current) main problem is the mixing of compilers so I would try to fix this issue first.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.