lammps-gui installation fails during latest steps of make install

Dear lammps-gui developper,
I just tried to install lammps-gui (from LAMMPS (29 Aug 2024 - Update 1)) for the first time on an Ubuntu 24.04.2 LTS system with an AMD Ryzen 9 7900X CPU, and a RX 7900 XT 20GB GPU.
I first compiled and installed LAMMPS with:

export HIP_PATH=/opt/rocm/hip
cmake -D CMAKE_INSTALL_PREFIX=/usr/local ../cmake -D PKG_EXTRA-FIX=yes -D PKG_ML-HDNNP=yes -D DOWNLOAD_N2P2=yes -D PKG_PLUMED=yes -D DOWNLOAD_PLUMED=yes -D PLUMED_MODE=static -D PKG_MOLECULE=yes -D PKG_REAXFF=yes -D BUILD_MPI=no -D BUILD_OMP=yes  -D PKG_OPENMP=yes -D PKG_MANYBODY=yes -D PKG_KOKKOS=yes -D Kokkos_ARCH_ZEN3=yes -D Kokkos_ARCH_AMD_GFX1100=yes -D Kokkos_ENABLE_HIP=yes -D Kokkos_ENABLE_OPENMP=yes -D PKG-VORONOI=yes -D DOWNLOAD_VORO=yes -D PKG_GPU=yes -D GPU_API=hip -D CMAKE_CXX_COMPILER=hipcc -D HIP_ARCH=gfx1100 -D HIP_PATH=/opt/rocm/hip/bin -D CMAKE_PREFIX_PATH=/opt/rocm/lib/cmake
sudo cmake --build . -j
sudo make install

It works as expected with our usual input scripts.

However reading through the documentation to search for the latest flags and get some new information, I read that there is now a LAMMPS GUI (THANKS Axel) which would ease the process of learning how to use LAMMPS for e.g. new PhD students. I wanted to try and I added “D BUILD_LAMMPS_GUI=on” to the cmake line. I first ran into some problems that I solved by installing some packages (sudo apt install qtbase5-dev libqt5charts5-dev)
Then the “cmake --build . -j” step finished without errors.
However, towards the end of the “sudo make install” step, I got the following error:

Install the project...
-- Install configuration: "RelWithDebInfo"
-- Installing: /usr/local/bin/lmp
-- Set non-toolchain portion of runtime path of "/usr/local/bin/lmp" to ""
-- Up-to-date: /usr/local/share/man/man1/lmp.1
-- Installing: /usr/local/bin/lammps-gui
-- Set non-toolchain portion of runtime path of "/usr/local/bin/lammps-gui" to ""
-- Up-to-date: /usr/local/share/applications/lammps-gui.desktop
-- Up-to-date: /usr/local/share/appdata/lammps-gui.appdata.xml
-- Up-to-date: /usr/local/share/mime/packages/lammps-input.xml
-- Up-to-date: /usr/local/share/mime/text/x-application-lammps.xml/lammps-input.xml
-- Up-to-date: /usr/local/share/icons//hicolor
-- Up-to-date: /usr/local/share/icons//hicolor/48x48
-- Up-to-date: /usr/local/share/icons//hicolor/48x48/apps
-- Up-to-date: /usr/local/share/icons//hicolor/48x48/apps/lammps.png
-- Up-to-date: /usr/local/share/icons//hicolor/64x64
-- Up-to-date: /usr/local/share/icons//hicolor/64x64/apps
-- Up-to-date: /usr/local/share/icons//hicolor/64x64/apps/lammps.png
-- Up-to-date: /usr/local/share/icons//hicolor/16x16
-- Up-to-date: /usr/local/share/icons//hicolor/16x16/apps
-- Up-to-date: /usr/local/share/icons//hicolor/16x16/apps/lammps.png
-- Up-to-date: /usr/local/share/icons//hicolor/128x128
-- Up-to-date: /usr/local/share/icons//hicolor/128x128/apps
-- Up-to-date: /usr/local/share/icons//hicolor/128x128/apps/lammps.png
-- Up-to-date: /usr/local/share/icons//hicolor/22x22
-- Up-to-date: /usr/local/share/icons//hicolor/22x22/apps
-- Up-to-date: /usr/local/share/icons//hicolor/22x22/apps/lammps.png
-- Up-to-date: /usr/local/share/icons//hicolor/32x32
-- Up-to-date: /usr/local/share/icons//hicolor/32x32/apps
-- Up-to-date: /usr/local/share/icons//hicolor/32x32/apps/lammps.png
CMake Error at lammps-gui-build/cmake_install.cmake:90 (file):
  file unknown error.
Call Stack (most recent call first):
  cmake_install.cmake:75 (include)

make: *** [Makefile:100 : install] Erreur 1

Furthermore, if I nonetheless try to run lammps-gui, I get

LAMMPS (29 Aug 2024 - Update 1)
  using 8 OpenMP thread(s) per MPI task
ERROR: Floating point number 1.0 in input script or data file is invalid (src/lammps-29Aug2024/src/lattice.cpp:58)
Last command: (unknown)
LAMMPS Exception: ERROR: Floating point number 1.0 in input script or data file is invalid (src/lammps-29Aug2024/src/lattice.cpp:58)

plus a window titled “Incompatible LAMMP Version@MN2S-DEVEL08”, with the text:
“LAMMPS-GUI version 1.6.10 requires
a LAMMPS version more recent than 2 August 2023”
and an OK button.
This seems contradictory with the fact that my LAMMPS version is LAMMPS (29 Aug 2024 - Update 1).
Browsing through the forum, I just saw a reply by Axel saying that LAMMPS-GUI is incompatible with kokkos. So that may be a problem, but I doubt it is the problem triggering my install error, since the build step completed successfully and the error is really in the latest steps of the install. Hence, I am a bit reluctant to recompile everything without kokkos and install it in a different location, but I could do it, if needed.
Looking forward for any help.
Sincerely yours,
Michel DEVEL

Never ever compile software as root. That is an invitation to ruin your Linux system. One typo in one of the scripts bundled with LAMMPS and it can destroy your Linux installation.

Same here. Actually, even more risky since files are copied to somewhere in /usr. That is why we use $HOME/.local as prefix. Most current Linux distributions already include $HOME/.local/bin into the search path by default.

I would have to see the exact contents of that file to determine what is failing.
The installation is likely incomplete, so you may want to try “sudo make -i install”
so that the installation will skip over the cmake error and try to continue. Perhaps
that helps, perhaps not.

That would likely be a syntax error in your input file with the lattice command.

This looks like corrupted memory. What is the output of?

ldd /usr/local/bin/lammps-gui

KOKKOS with GPUs is not supported (for technical reasons), KOKKOS with OpenMP is.

You should be able to run ./lammps-gui in the build folder.

I would suggest to not mess with your text mode LAMMPS installation (then you can include support for MPI, which is highly recommended for maximum efficiency), but leave out LAMMPS-GUI and instead download a pre-compiled package from: Releases ¡ lammps/lammps ¡ GitHub
Those executables should work on most Linux machines and very likely on your machine. It should support your GPU via OpenCL (but that is a bit of a lottery with either Nvidia or AMD GPUs these days).

Hi Axel,
Thanks for the answers!
Concerning lammps-gui-build/cmake_install.cmake I did not make any change to it manually. It is the one created by cmake Since I am a new user of the forum, I cannot upload files, hence I incorporate it hereafter:

# Install script for directory: /usr/local/src/lammps-29Aug2024/tools/lammps-gui

# Set the install prefix
if(NOT DEFINED CMAKE_INSTALL_PREFIX)
  set(CMAKE_INSTALL_PREFIX "/usr/local")
endif()
string(REGEX REPLACE "/$" "" CMAKE_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}")

# Set the install configuration name.
if(NOT DEFINED CMAKE_INSTALL_CONFIG_NAME)
  if(BUILD_TYPE)
    string(REGEX REPLACE "^[^A-Za-z0-9_]+" ""
           CMAKE_INSTALL_CONFIG_NAME "${BUILD_TYPE}")
  else()
    set(CMAKE_INSTALL_CONFIG_NAME "RelWithDebInfo")
  endif()
  message(STATUS "Install configuration: \"${CMAKE_INSTALL_CONFIG_NAME}\"")
endif()

# Set the component getting installed.
if(NOT CMAKE_INSTALL_COMPONENT)
  if(COMPONENT)
    message(STATUS "Install component: \"${COMPONENT}\"")
    set(CMAKE_INSTALL_COMPONENT "${COMPONENT}")
  else()
    set(CMAKE_INSTALL_COMPONENT)
  endif()
endif()

# Install shared libraries without execute permission?
if(NOT DEFINED CMAKE_INSTALL_SO_NO_EXE)
  set(CMAKE_INSTALL_SO_NO_EXE "1")
endif()

# Is this installation the result of a crosscompile?
if(NOT DEFINED CMAKE_CROSSCOMPILING)
  set(CMAKE_CROSSCOMPILING "FALSE")
endif()

# Set default install directory permissions.
if(NOT DEFINED CMAKE_OBJDUMP)
  set(CMAKE_OBJDUMP "/usr/bin/objdump")
endif()

if(CMAKE_INSTALL_COMPONENT STREQUAL "Unspecified" OR NOT CMAKE_INSTALL_COMPONENT)
  if(EXISTS "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/lammps-gui" AND
     NOT IS_SYMLINK "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/lammps-gui")
    file(RPATH_CHECK
         FILE "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/lammps-gui"
         RPATH "")
  endif()
  file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/bin" TYPE EXECUTABLE FILES "/usr/local/src/lammps-29Aug2024/build/lammps-gui")
  if(EXISTS "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/lammps-gui" AND
     NOT IS_SYMLINK "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/lammps-gui")
    file(RPATH_CHANGE
         FILE "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/lammps-gui"
         OLD_RPATH "/opt/rocm-6.3.3/lib/llvm/lib:"
         NEW_RPATH "")
    if(CMAKE_INSTALL_DO_STRIP)
      execute_process(COMMAND "/usr/bin/strip" "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/lammps-gui")
    endif()
  endif()
endif()

if(CMAKE_INSTALL_COMPONENT STREQUAL "Unspecified" OR NOT CMAKE_INSTALL_COMPONENT)
  include("/usr/local/src/lammps-29Aug2024/build/lammps-gui-build/CMakeFiles/lammps-gui.dir/install-cxx-module-bmi-RelWithDebInfo.cmake" OPTIONAL)
endif()

if(CMAKE_INSTALL_COMPONENT STREQUAL "Unspecified" OR NOT CMAKE_INSTALL_COMPONENT)
  file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/share/applications" TYPE FILE FILES "/usr/local/src/lammps-29Aug2024/tools/lammps-gui/lammps-gui.desktop")
endif()

if(CMAKE_INSTALL_COMPONENT STREQUAL "Unspecified" OR NOT CMAKE_INSTALL_COMPONENT)
  file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/share/appdata" TYPE FILE FILES "/usr/local/src/lammps-29Aug2024/tools/lammps-gui/lammps-gui.appdata.xml")
endif()

if(CMAKE_INSTALL_COMPONENT STREQUAL "Unspecified" OR NOT CMAKE_INSTALL_COMPONENT)
  file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/share/mime/packages" TYPE FILE FILES "/usr/local/src/lammps-29Aug2024/tools/lammps-gui/lammps-input.xml")
endif()

if(CMAKE_INSTALL_COMPONENT STREQUAL "Unspecified" OR NOT CMAKE_INSTALL_COMPONENT)
  file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/share/mime/text/x-application-lammps.xml" TYPE FILE FILES "/usr/local/src/lammps-29Aug2024/tools/lammps-gui/lammps-input.xml")
endif()

if(CMAKE_INSTALL_COMPONENT STREQUAL "Unspecified" OR NOT CMAKE_INSTALL_COMPONENT)
  file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/share/icons/" TYPE DIRECTORY FILES "/usr/local/src/lammps-29Aug2024/tools/lammps-gui/icons/hicolor")
endif()

if(CMAKE_INSTALL_COMPONENT STREQUAL "Unspecified" OR NOT CMAKE_INSTALL_COMPONENT)
      file(GET_RUNTIME_DEPENDENCIES
      LIBRARIES /usr/local/src/lammps-29Aug2024/build/liblammps.a
      EXECUTABLES /usr/local/src/lammps-29Aug2024/build/lammps-gui /usr/local/src/lammps-29Aug2024/build/lmp
      RESOLVED_DEPENDENCIES_VAR _r_deps
      UNRESOLVED_DEPENDENCIES_VAR _u_deps
    )
    foreach(_file ${_r_deps})
      file(INSTALL
        DESTINATION "${CMAKE_INSTALL_PREFIX}/lib"
        TYPE SHARED_LIBRARY
        FOLLOW_SYMLINK_CHAIN
        FILES "${_file}"
      )
    endforeach()
    list(LENGTH _u_deps _u_length)
    if("${_u_length}" GREATER 0)
      message(WARNING "Unresolved dependencies detected: ${_u_deps}")
    endif() 
endif()

the output of sudo make -i install is the same as in my first message. The last lines are still:

CMake Error at lammps-gui-build/cmake_install.cmake:90 (file):
  file unknown error.
Call Stack (most recent call first):
  cmake_install.cmake:75 (include)

Concerning

ERROR: Floating point number 1.0 in input script or data file is invalid (src/lammps-29Aug2024/src/lattice.cpp:58)

I really do not understand it because I did not add any script name when I tried to launch lammps-gui:

(base) michel.devel@MN2S-DEVEL08:/usr/local/src/lammps-29Aug2024/build$ ./lammps-gui
LAMMPS (29 Aug 2024 - Update 1)
  using 24 OpenMP thread(s) per MPI task
ERROR: Floating point number 1.0 in input script or data file is invalid (src/lammps-29Aug2024/src/lattice.cpp:58)
Last command: (unknown)
LAMMPS Exception: ERROR: Floating point number 1.0 in input script or data file is invalid (src/lammps-29Aug2024/src/lattice.cpp:58)

For /usr/local/bin/lammps-gui I first got

/usr/local/bin/lammps-gui: error while loading shared libraries: libomp.so: cannot open shared object file: No such file or directory

Then I did export LD_LIBRARY_PATH=/opt/rocm/lib/llvm/lib:$LD_LIBRARY_PATH and then
/usr/local/bin/lammps-gui gave me exactly the same error message as above for ./lammps-gui in the build folder…

Concerning the output of ldd /usr/local/bin/lammps-gui, here it is:

        linux-vdso.so.1 (0x00007ffd0d5ad000)
        libQt5Charts.so.5 => /lib/x86_64-linux-gnu/libQt5Charts.so.5 (0x00007faa47c7b000)
        libcurl-gnutls.so.4 => /lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007faa47bc0000)
        libjpeg.so.8 => /lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007faa47b3d000)
        libopenblas.so.0 => /lib/x86_64-linux-gnu/libopenblas.so.0 (0x00007faa45600000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007faa47a52000)
        libgsl.so.27 => /lib/x86_64-linux-gnu/libgsl.so.27 (0x00007faa45200000)
        libgslcblas.so.0 => /lib/x86_64-linux-gnu/libgslcblas.so.0 (0x00007faa47a12000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007faa479f6000)
        libfftw3.so.3 => /lib/x86_64-linux-gnu/libfftw3.so.3 (0x00007faa44e00000)
        libomp.so => /opt/rocm/lib/llvm/lib/libomp.so (0x00007faa45506000)
        libamdhip64.so.6 => /opt/rocm-6.3.3/lib/llvm/bin/../../../lib/libamdhip64.so.6 (0x00007faa43600000)
        libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x00007faa42e00000)
        libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x00007faa42600000)
        libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 (0x00007faa42000000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007faa41c00000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007faa454d8000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faa41800000)
        /lib64/ld-linux-x86-64.so.2 (0x00007faa47e64000)
        libnghttp2.so.14 => /lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007faa454ad000)
        libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007faa451de000)
        librtmp.so.1 => /lib/x86_64-linux-gnu/librtmp.so.1 (0x00007faa451c0000)
        libssh.so.4 => /lib/x86_64-linux-gnu/libssh.so.4 (0x00007faa4514f000)
        libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x00007faa479dc000)
        libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 (0x00007faa450fa000)
        libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007faa41606000)
        libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007faa450a6000)
        libldap.so.2 => /lib/x86_64-linux-gnu/libldap.so.2 (0x00007faa45048000)
        liblber.so.2 => /lib/x86_64-linux-gnu/liblber.so.2 (0x00007faa45036000)
        libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007faa44d46000)
        libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007faa45028000)
        libgfortran.so.5 => /lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007faa41200000)
        librocprofiler-register.so.0 => /opt/rocm-6.3.3/lib/llvm/bin/../../../lib/librocprofiler-register.so.0 (0x00007faa44cc1000)
        libamd_comgr.so.2 => /opt/rocm-6.3.3/lib/llvm/bin/../../../lib/libamd_comgr.so.2 (0x00007faa38600000)
        libhsa-runtime64.so.1 => /opt/rocm-6.3.3/lib/llvm/bin/../../../lib/libhsa-runtime64.so.1 (0x00007faa38200000)
        libnuma.so.1 => /lib/x86_64-linux-gnu/libnuma.so.1 (0x00007faa44cb3000)
        libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007faa43579000)
        libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007faa44c7b000)
        libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007faa41ef3000)
        libmd4c.so.0 => /lib/x86_64-linux-gnu/libmd4c.so.0 (0x00007faa43567000)
        libdouble-conversion.so.3 => /lib/x86_64-linux-gnu/libdouble-conversion.so.3 (0x00007faa43552000)
        libicui18n.so.74 => /lib/x86_64-linux-gnu/libicui18n.so.74 (0x00007faa37e00000)
        libicuuc.so.74 => /lib/x86_64-linux-gnu/libicuuc.so.74 (0x00007faa37a00000)
        libpcre2-16.so.0 => /lib/x86_64-linux-gnu/libpcre2-16.so.0 (0x00007faa434c6000)
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007faa41ab7000)
        libunistring.so.5 => /lib/x86_64-linux-gnu/libunistring.so.5 (0x00007faa37c53000)
        libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 (0x00007faa42db8000)
        libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007faa42d34000)
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007faa37400000)
        libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007faa3725c000)
        libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007faa42d1e000)
        libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007faa4153d000)
        libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007faa425d4000)
        libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007faa44c71000)
        libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007faa42d11000)
        libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007faa425ba000)
        libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007faa42597000)
        libelf.so.1 => /lib/x86_64-linux-gnu/libelf.so.1 (0x00007faa42578000)
        libdrm.so.2 => /opt/amdgpu/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007faa42cf8000)
        libdrm_amdgpu.so.1 => /opt/amdgpu/lib/x86_64-linux-gnu/libdrm_amdgpu.so.1 (0x00007faa41ee4000)
        libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007faa41148000)
        libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007faa41eb1000)
        libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007faa37934000)
        libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007faa41e8b000)
        libicudata.so.74 => /lib/x86_64-linux-gnu/libicudata.so.74 (0x00007faa35400000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007faa41a1d000)
        libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007faa41e7f000)
        libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007faa434bd000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007faa4152a000)
        libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007faa352c3000)
        libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007faa41134000)
        libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007faa4110b000)
        libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007faa41a17000)
        libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007faa41522000)
        libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007faa410f5000)
        libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x00007faa410e6000)

Concerning the reasons of my using sudo, it is because I want to install the same version of LAMMPS for all the users of that machine (people from my group), not only me.
Furthermore, I did not want to use a pre-compiled binary because I think I have been using lammps for more than a decade now and some times I was missing some package e.g. in the Windows version (which was nonetheless very useful for internships or for hands on classes when I was teaching Molecular Dynamics to beginners for example) or even in the linux version. Hence I have experiment in compling LAMMPS from source and chosing the packages I want to add and do not mind doing it. This time, it is because of the use of GPU version with my particular GPU and also because of the EXTRA-FIX package.

Finally, I must admit that I do not understand why using MPI instead of OpenMP would be more efficient on our single node machine with only one CPU and one GPU, but I am ready to learn why and change my mind! :wink:

Thanks again for your help,
Michel DEVEL

This is a short file, so it is OK.

This is the line that is failing. Perhaps there is a bug in your cmake installation, or you could have multiple versions of cmake installed and make install picks up a different on. This line should work for CMake 3.16 and later, which is a requirement for compiling your version of LAMMPS with CMake in the first place.

Neither do I, but please try executing:

export LC_ALL=C

Before you run LAMMPS-GUI.

That is easily avoided. Create a new user without any special privileges used for compiling software, we usually call it “install”. Then use chown -R install:install /usr/local. And now you can do sudo su -l install to become the install user and compile and install without any root privilege needed into /usr/local. The install user can only mess up anything in /usr/local. Much safer.

LAMMPS is from ground up designed for MPI parallel calculations using domain decomposition. That means everything in LAMMPS is MPI parallel. OpenMP multi-threading requires extra parts of the code to be explicitly multi-threaded. Only a subset is supported, a larger subset with the OPENMP package, a smaller subset with the KOKKOS package and an even smaller subset with the INTEL package (which can be used in hybrid mode with OPENMP through). With multi-threading you have a race condition problem with computing forces when using newton’s third law (and avoid computing all pairwise forces twice). Typical ways to resolve them are atomic add operations, not using newton’s third law or using per-thread replicated force arrays. The first is quite slow considering how fast classical potentials are, the second doubles the computation effort, the third requires a reduction across all threads, which has increasing overhead the more threads you use. Also you are less cache efficient since you need to access the per-thread per-atom data. With MPI and domain decomposition, however, the number of atoms and the force loops get smaller the more subdomains you have, which increases cache efficiency. Only if you have too many processes, you have more overhead due to the “ghost” atoms required.
The only significant problem with MPI and domain decomposition is when you have an inhomogeneous system, since that will lead to load imbalances. Those are smaller with threading, since you distribute the loops over atoms across all threads and those pay little attention to the local density (it does affect the list of neighbors somewhat though).

As a simple exercise, try running the bench/in.lj input as follows and compare the timing.

mpirun -np 1 env OMP_NUM_THREADS=8 ./lmp -in ../bench/in.lj -v x 4 -v y 4 -v z 4 -sf omp

mpirun -np 8 env OMP_NUM_THREADS=1 ./lmp -in ../bench/in.lj -v x 4 -v y 4 -v z 4

I am suggesting the pre-compiled binaries to have a starting point of reference. If that has the same issues on your machine as the binary you compile yourself, then we have to figure out what it is that makes your machine different from others.

Then I would build the LAMMPS-GUI version first with minimal settings and then add features step by step until you run into trouble. As already mentioned, KOKKOS with GPU will not work and create problems, since when you enable GPU support in KOKKOS you must use it or you cannot use KOKKOS at all (for threads only). Also, the compiler/library issues are avoided when compiling the GPU package for OpenCL (which is supported by AMD GPUs and Nvidia GPUs and Intel GPUs). The performance differences don’t matter for the GUI version (same the lack of MPI).

I would also suggest to try the 4 Feb 2025 version, or the “maintenance” branch from github which have updates to LAMMPS GUI.

1 Like

Axel,
Thanks a lot for these detailed explanations!
I will try to follow your advices (including the “install” user that seems indeed so simple and effective that I am a bit pitiful to have not done that before).
First result is a very positive one: export LC_ALL=C seems to have solved the problem with lammps-gui!
Second result is that with the lmp compiled with the options given in my original post the first test with in.lj (with np 1 env OMP_NUM_THREADS=8) takes between 12 and 13s wall time

Performance: 3860.184 tau/day, 8.936 timesteps/s, 18.300 Matom-step/s
787.8% CPU use with 1 MPI tasks x 8 OpenMP threads

while the second (with -np 8 env OMP_NUM_THREADS=1) took about 61s wall time spawning 8 different processes whith each their own output similar to

Performance: 743.735 tau/day, 1.722 timesteps/s, 3.526 Matom-step/s
100.0% CPU use with 1 MPI tasks x 1 OpenMP threads

Well, I think I should redo these tests after recompiling without -D BUILD_MPI=no ! :wink:
I shall report other results when I will have tested the other advices given in your post, but for me the provisional solution to my initial post is indeed to execute export LC_ALL=C before launching lammps-gui

Thanks a lot!!!

Sincerely yours,
Michel DEVEL

Thanks for confirming my suspicion. That actually constitutes a bug in LAMMPS-GUI. It is supposed to enforce switching to the C locale (like all scientific programs should). ‘Native language support is evil™’ and has caused quite a bit of harm by putting and expecting a comma where a dot should be and vice versa. I am looking for alternatives to achieve this.

If you got multiple outputs in the case of the openMPI run, your executable was compiled in the serial mode, so you actually didn’t see the speedup. If ran correctly, you should see something like 100.0% CPU use with 8 MPI tasks x 1 OpenMP threads.

I recompiled LAMMPS with -D BUILD_MPI=yes instead of -D BUILD_MPI=no and tried to redo the two tests proposed by Axel, but using mpirun I keep getting 8 independant processes. I then use whereis mpirun, which mpirun and ls /usr/bin/mpi* to understand better the situation.
the result is that mpirun is an Intel version and that I should use mpirun.openmpi to use the openmpi version

mpirun --version
Intel(R) MPI Library for Linux* OS, Version 2021.14 Build 20250213 (id: 0d7f579)
Copyright 2003-2025, Intel Corporation.

mpirun.openmpi --version
mpirun.openmpi (OpenRTE) 4.1.6

With mpirun.openmpi I get the expected behaviour:

Performance: 5051.450 tau/day, 11.693 timesteps/s, 23.948 Matom-step/s
99.0% CPU use with 8 MPI tasks x 1 OpenMP threads

with a Real time of 9.168 s (wall time of 0:00:08 for LAMMPS)

However, when I tried time mpirun.openmpi -np 1 env OMP_NUM_THREADS=8 lmp -in /usr/local/share/lammps/bench/in.lj -v x 4 -v y 4 -v z 4 -sf omp
I got a real time of 39.712s (Total wall time: 0:00:39 for LAMMPS)
while time mpirun -np 1 env OMP_NUM_THREADS=8 lmp -in /usr/local/share/lammps/bench/in.lj -v x 4 -v y 4 -v z 4 -sf omp resulted in a real time of 10.457s (Total wall time: 0:00:10 for LAMMPS) hence almost as fast as the run with time mpirun.openmpi -np 8 env OMP_NUM_THREADS=1 lmp -in /usr/local/share/lammps/bench/in.lj -v x 4 -v y 4 -v z 4

It seems I should have a look at which MPI library was used by hipcc to compile LAMMPS!..

PS: even if I export LC_ALL=C before recompiling I still have the previous error at install time:

CMake Error at lammps-gui-build/cmake_install.cmake:90 (file):
  file unknown error.
Call Stack (most recent call first):
  cmake_install.cmake:75 (include)

make: *** [Makefile:100: install] Error 1

Yours siincerely,
Michel DEVEL

I cannot reproduce this (unlike the Floating point number 1.0 in input script or data file is invalid error) and thus cannot diagnose and resolve it. Given that your other reports indicate a rather inconsistent installation with colliding or overlapping software packages, it is most likely that this is a specific issue of your system setup. There are no issues when compiling and installing on a plain Ubuntu 22.04LTS (virtual) machine with default GCC and default MPI (i.e. OpenMPI) or default Clang compiler and no other compiler or MPI library installed.

The pre-compiled LAMMPS-GUI package comes with the following configuration:

This is LAMMPS-GUI version 1.6.12 using Qt version 5.12.8 using light theme
LAMMPS library linked to executable

LAMMPS version: 4 Feb 2025 / 20250204
Git info: release / patch_4Feb2025 / c10219da9e366addec5aa2be8883fe9c419d91a0

OS information: Linux "Fedora Linux 41 (Forty One)" 6.13.5-200.fc41.x86_64 x86_64

sizeof(smallint): 32-bit
sizeof(imageint): 32-bit
sizeof(tagint):   32-bit
sizeof(bigint):   64-bit

Compiler: GNU C++ 9.4.0 with OpenMP 4.5
C++ standard: C++17
Embedded fmt library version: 10.2.0

Active compile time flags:

-DLAMMPS_GZIP
-DLAMMPS_PNG
-DLAMMPS_JPEG
-DLAMMPS_CURL
-DLAMMPS_SMALLBIG

Available compression formats:

Extension: .gz     Command: gzip
Extension: .bz2    Command: bzip2
Extension: .zst    Command: zstd
Extension: .xz     Command: xz
Extension: .lzma   Command: xz
Extension: .lz4    Command: lz4


Installed packages:

AMOEBA ASPHERE AWPMD BOCS BODY BPM BROWNIAN CG-DNA CG-SPICA CLASS2 COLLOID 
COLVARS COMPRESS CORESHELL DIELECTRIC DIFFRACTION DIPOLE DPD-BASIC DPD-MESO 
DPD-REACT DPD-SMOOTH DRUDE EFF ELECTRODE EXTRA-COMMAND EXTRA-COMPUTE 
EXTRA-DUMP EXTRA-FIX EXTRA-MOLECULE EXTRA-PAIR FEP GPU GRANULAR INTEL 
INTERLAYER KSPACE LEPTON MACHDYN MANIFOLD MANYBODY MC MEAM MESONT MISC 
ML-HDNNP ML-IAP ML-PACE ML-POD ML-RANN ML-SNAP ML-UF3 MOFFF MOLECULE MOLFILE 
OPENMP OPT ORIENT PERI PHONON PLUGIN POEMS PTM QEQ QTB REACTION REAXFF REPLICA 
RIGID SHOCK SMTBQ SPH SPIN SRD TALLY UEF VORONOI YAFF 

is there anything specific that you are missing from that?

Very probably no! :wink:
My motivation to compile LAMMPS came from the fact that I wanted to try using kokkos to speed up ReaxFF using our GPU, but I still did not had time to see whether it would really speed up in our specific use case (soot particles with some oxygen atoms in various chemical functions).

Also I agree that my installation has overlapping and possibly colliding software packages since I also develop and maintain some home/lab-made fortran codes and like to have several compilers at hand when I have a nasty bug to find, with unfortunately no time to try containers (I used modules on a previous machine, but did not have time to do that again on the current machine).

Hence, I consider that my problem is satisfactorily solved (and that I learnt plenty of interesting things in this conversation that will help me improve my using of this development machine) and thank you again, Alex, for that!

Yes, environment modules are the way to go to handle such a situation.
You may also want to have a look into spack (https://spack.io/) that can help building the various packages and tools consistently and keeping the “dependency hell” in check.

Another set of options, that we use extensively when testing and debugging LAMMPS on various different environments are containers (via apptainer) or virtual machines (via VirtualBox for non-Linux environments). For example, I have ready-to-use containers with all tools required for compiling and debugging LAMMPS for a variety of Linux flavors (Ubuntu, Fedora, AlmaLinux, Debian) and a variety of versions and a variety of compiler/GPU support (Intel, Nvidia, AMD), and a bunch of virtual box instances for Windows, macOS, and FreeBSD. This way, I can keep my main OS installation “clean”.

I also advise to turn off native language support to avoid unexpected failures due to localized number formats.

A general additional comment, if your purpose for LAMMPS-GUI is to help orientate new PhD students:

They may well do better by directly learning an analysis and visualisation package alongside LAMMPS. Both MDAnalysis and ASE (Atomic Simulation Environment) are reasonably robust and performant analysis environments which can load in data files, load trajectories “progressively” (only loading frames into memory as needed), and visualise conformations inside a Jupyter Notebook interface with NGLView.

Indeed, I read some positive comments on spack and the flexibility it brings. However, I am still in the process of learning how to use guix (GNU Guix transactional package manager and distribution — GNU Guix) since it seems that it could be very helpful for reproducible research over the years. All these tools are certainly very useful and time savers, … once you have invested some time to use them!..

I already talked of ASE to my current PhD students though he also has plenty of codes to learn (octopus, LAMMPS, our own codes), but I am indeed convinced that postprocessing environments scriptable with python are a good way to go!
Thanks for the advice.