Hello Tomas,

This is unfortunately a reasonably common occurrence if the modules / OS do not set all paths or LD_LIBRARY_PATH.

Usually we fix this by setting --rpath options ion lDFLAGS. See eg

https://bitbucket.org/simfactory/simfactory2/src/master/mdb/optionlists/supe...

Note: generic is really designed for local workstations and may not work well on a cluster (certainly generic.sub will not since it does not use any queuing system).

See eg

http://einsteintoolkit.org/seminars/2022_02_24/index.html

for a presentation on how to set up on a new cluster. It links to more documentation in the jupyter notebook that is used for the presentation.

By "exporting the paths" you mean something like:

export LD_LIBRARY_PATH=path-to-directory-containing-libfabrics

? If so then the --rpath option above does something similar but only for the single executable that is being linked (so nicer to your environment).

Yours, Roland

Hi,

I’m installing the toolkit in this machine https://urldefense.com/v3/__https://www.nlhpc.cl/infraestructura/__;!!DZ3fjg... . The documentation is in spanish but the relevant specs are:

128 nodes HPE ProLiant SL230s Gen8 each node with two CPUs Intel Xeon E5-2660 v2 OS: CentOS 7

I am able to compile using the generic.cfg file, loading the following modules

GCCcore/8.2.0 GCC/8.2.0-2.31.1 icc/2019.2.187-GCC-8.2.0-2.31.1-nlhpc impi/2019.2.185 imkl/2019.2.187 Szip/2.1.1 HDF5/1.10.6 binutils/2.32 zlib/1.2.11 OpenMPI/3.1.3 hwloc/2.4.1

However, if I try to run a simulation I get errors:

• error while loading shared libraries: libifport.so.5: cannot open shared

object file: No such file or directory

• and similarly error while loading shared libraries: libfabric.so.1

After some googling, I managed to fix these errors by exporting the paths of the files libifport.so.5, libfabric.so.1 but this seems a bit strange and I am wondering if I can instead get the code to work by loading the correct modules only.

Any thoughts?

Thank you! Tomas