Issue about installing LAMMPS Python module and implement it – LAMMPS Installation

Please note that the latest feature release of LAMMPS is version 8 Feb 2023.

This looks very wrong.

From your description it seems that the “full install” is not the best choice. That would be the case, if your target folder would be some folder like /usr/local or ${HOME}/.local or similar. The corresponding “bin” and “lib” or “lib64” folders would need to be referenced in ${PATH} and ${LD_LIBRARY_PATH} (or ${DLYD_LIBRARY_PATH} on macOS), respectively.

Instead what would serve you better would be to not do cmake --install, but rather cmake --build . --target install-python. That does two things:

  1. build a so-called “wheel” file. That should be named for your version lammps-2022.11.3-cp310-cp310-linux_x86_64.whl (with python 3.10)
  2. install this “wheel” into your global python environment with python -m pip install lammps-2022.11.3-cp310-cp310-linux_x86_64.whl

You don’t really need the second part and can easily undo it with python -m pip uninstall lammps to avoid confusion over which LAMMPS Python module environment is used.
You want to keep the wheel file, as that has your LAMMPS shared library and python module bundled ready for installation with pip.

Then, whenever you set up a virtual environment, you can add the LAMMPS Python module to it with python -m pip install lammps-2022.11.3-cp310-cp310-linux_x86_64.whl

This is what Python is looking for on most machines (macOS and Windows are different). The lib vs lib64 is a Linux x86 specialty and not relevant for python. It assumes that you have only one viable platform locally.

This is a side effect of the “strange” choice of making your build folder the install folder. The two shared library files are essentially the same. Only the one in “build” is the original and the one in build/lib64 the “installed” version that has been modify to remove the hard coded “rpath” entry for the build folder.

lammps package in this context refers to the LAMMPS python module, and thus would be the site-packages folder.

Your questions indicate, that you are conflating the way of using LAMMPS with a full installation and the use of LAMMPS and its python module directly from the build folder. In the latter case, no cmake --install . or make install is needed or use, but instead ${PATH} and ${LD_LIBRARY_PATH} augmented to directly point to the build folder and PYTHONPATH needs to point to the python folder of the LAMMPS source code. This is why using the wheel package and installing it into the individual virtual environment is preferred, since that one does not require any updates of environment variables for using the LAMMPS python module.

Your guess is wrong. However strange your LAMMPS configuration and installation procedure, it could not lead to this kind of segmentation fault.

If you look at the paths you can see that this originates from issues with your “mpi4py” installation, which has problems initializing your OpenMPI environment. There is no mention of LAMMPS anywhere in the stack trace, so that seems to be happening before LAMMPS itself is executed. LAMMPS is loading mpi4py, if available so you can run on a sub-communicator, if desired.

I suggest you run some simple tests to verify that mpi4py on its own is working correctly.

Read more here: Source link