Today I would like to draw your attention to an experiment that may help people to get started with LAMMPS faster and lower the barrier to test your inputs with the latest LAMMPS versions before reporting a bug. Most people will need to compile LAMMPS themselves from source and that can be a challenging tasks, if you are lacking the experience. Compilation with additional packages and their libraries is even more challenging. When installing through a package manager, you are, on the other hand, limited by the choices of the person packaging LAMMPS. So the intent is to provide an executable that requires no compilation or special installation, but you can just unpack the archive and get started by running it.
If you go to this LAMMPS Downloads website, you can now download tar archives with precompiled LAMMPS binaries that should work on any 64-bit x86 Linux machine. These have been built with almost all packages included (see below). Only MPI and Python support are missing, since MPI has to match the locally installed MPI library, and Python requires bundling a complete Python installation. All you need to run LAMMPS is the LAMMPS executable “lmp”, so it can be moved to a different location without worrying about (shared) libraries etc. Several add-on tools are included as well.
I am making this post in the forum now in order to get some crucial feedback from users. What I want to know is the following:
Does the executable run on your Linux machine? Please report if not, and provide details about your Linux OS and hardware
Is this useful? Specifically, have you tried to report a bug and had to struggle because you were asked to test your input with the latest version of LAMMPS?
Is this sufficient for your production calculations (i.e. is having only OpenMP parallelization via the OPENMP and INTEL package and no MPI support running your simulations fast enough)?
Is there something missing that is important to you?
Any additional suggestions are welcome, too.
Thanks in advance for any feedback.
Axel.
Here are the specs of the first available archive built from the latest stable release sources. More to come.
Unsurprisingly, this gives a cannot execute binary file: Exec format error on the Power9 CPUs of Summit (ORNL). Maybe it works with all x86_64 Linux machines, but not ppc64
Even if it did work, though, I wouldn’t likely use it, as it’s missing GPU acceleration, which I use for coarse-grained simulations, and I expect that’s not something that’s reasonable to precompile.
Sorry about the vagueness. This was meant to be for x86-only. That doesn’t mean that power is not possible, it just requires a different binary. I don’t expect people who have access to machines like Summit to have problems compiling executables, though.
Even worse, it is not possible. These are “true static” binaries, which means they cannot load any kind of shared library or object at runtime unless it is not fully self-contained, i.e. has no dependency on libc.so.x or libcuda.so.x etc. The most portable way to include GPU support would be the GPU package in OpenCL mode. We do that with the Windows binaries, but that requires loading the platform specific accelerator support via shared objects, so it is not possible here.
That said, it is quite impressive that it would be possible to compile executables on Fedora 37, that can also run on Ubuntu 16.04LTS and Ubuntu 22.04LTS at the same time. Normally that would cause all kinds of issues with the shared libraries.
Update: now there is a version of the latest development version in addition to the latest stable version. Both variants now also include Kokkos with OpenMP as additional package.
There are multiple reasons for that. The most important is that these styles are very aggressive in how they optimize and they have different heuristics for some of the automatic parameters.
So the results are a bit more approximate than for the other kspace styles. The unit tests don’t really test for correctness (they break for many tests with very aggressive optimization) but for reproducibility.
The biggest problem with the INTEL package in these binaries is that those binaries are not compiled with the Intel compilers, so they are missing many of the SIMD optimizations, so the OPENMP package code is often just as fast and sometimes even faster.
Here is a comparison of the rhodo benchmark output (openmp is left, default is middle, intel is right):
Just posted new packages with the latest updates to the develop branch and the update branch for the stable release to the LAMMPS download area
Please give them a try and let me know of any problems. This time even more packages are inlcuded and also the LAMMPS Shell can now be built as true static binary and is included.
For your convenience, I’ve added matching PDF versions of the LAMMPS manual for download.
I found the universal binary very useful, especially when working on university servers whose OS is outdated and unable to compile the latest version of LAMMPS. I can happily say that the universal binary works on Ubuntu Xenial (16.04).
Can you share the exact procedure to compile a universal binary? I’d like to deploy my custom-modified version, too
This is a bit tricky business. Let me first give you the outline so you can tell me, if you feel up to it, before I look up and reconstruct all the necessary steps and details.
You first need to build a Linux-2-Linux cross-compiler that uses musl-libc instead of glibc
Then you need to create a suitable CMake toolchain file
Then you need to build a few libraries with the cross-compiler so that more packages and tools can be included
Then you need to check out a sufficiently recent LAMMPS version
Then build the LAMMPS and other executables with CMake using the custom toolchain file
For 1. I found a set of scripts on GitHub, for 2. I looked at the file for the Linux-2-Windows cross compiler that exists as RPMs for Fedora Linux. I don’t recall how much porting was required for 3. Having to compile libtermcap certainly took me back to my “salad days”, but that is only needed for libreadline, which in turn is required for the lammps shell only. 4. and 5. are straightforward, if the rest was successful.
Thanks for the feedback. The procedure is definitely outside my comfort zone: I will ask for help and get back to you if there is a chance we will succeed.
I understand. I have been building compilers and cross-compilers (and using cross-compilers, too) from source for a living since I was a grad student some 20+ years ago. So these things don’t scare me anymore. One of the few perks of being an old fart that has been around the block a few times.
On second thought, I might be able to bundle my copy of the cross-compiler and the libraries into a singularity/apptainer container based on the same Fedora Linux version that I am using. That would reduce the steps you would have to do to the the last two (plus installing apptainer, if not already available).
Axel, thank you for your offer but let me first try to solve the issue with the help of my colleagues. Actually, there is only one file that gives an error, otherwise, the unmodified files still compile with the standard make. Sadly, it was never on my radar to become a software engineer --despite having enjoyed using Linux since 1998 (I think it was a Mandrake CD attached to a computer magazine).
Nostalgia mode: off!
It is a new bond style that Matteo Ricci developed for ellipsoids. When it’s time to push this stuff into the official LAMMPS pool, I will ask if you want to review the paper and the attached code. Meanwhile, you can see what it does in this video: CG deposition of BPAPF and m-MTDATA on a flat Lennard-Jones wall - YouTube.
I created the singularity/apptainer container image, anyway. It made sense for the symmetry of it. Now you can not only have LAMMPS binaries that can run on any x86_64 Linux box, but also create them on any platform where you can run the container.
