Open clarkedavida opened 1 year ago
If the binary needs to access some library, then I think strategy 2 will not work, right?
In case that getting this to work on supercomputers is a significant undertaking that neither of us has time for:
Maybe we can recommend the container_build for local use only, which is still beneficial to some of us. Then for the supercomputer build we can use the already existing instructions, or possibly streamline that with bash scripts? For a couple clusters, I already have such scripts.
Just a thought.
It's telling you that you compiled it against libmpi_cxx.so and that the supercomputer you're running against doesn't have that shared library in path. That tells me that the supercomputer in question is using a different MPI library and you need to compile against that MPI library or you need to make sure that libmpi_cxx.so is in the load library path
We are trying a couple strategies to run on a supercomputer.
Strategy 1: Compile on supercomputer. I am tabulating here which clusters start with podman and which don't. It would be ideal to eliminate having to contact a sysadmin to run on supercomputers.
PODMAN: notchpeak, houston
NO PODMAN: bielefeld, juwels
Strategy 2: Compile locally, then run on supercomputer.
This doesn't seem to work in the general case. For example compiling
GenerateQuenched
locally, then running on bielefeld, I get the errorThis
mpiexec --oversubscribe -np 1
command is what I do to run interactively, which works when I compile the traditional way.