Can I build two different versions of LAMMPS on my machine?
(by using the make command)
Could they interfere with each other during simulation?
Generally speaking it’s fine. I used to have two lammps installations on my own machine, and many HPC clusters provide multiple versions of lammps which you can load with the module system.
Note that you should set different install directories for them (typically not in default locations) to avoid them overwriting each other or library conflicts, and load corresponding environmental variables first before running each instance.
I’d also suggest using same the toolchain (compiler, mpi, CUDA toolkits, etc.) for both installation when possible to avoid potential problems, though this is not necessary if you can handle the environmental variables properly.
2 Likes
With make it’s harder to manage since that procedure compiles to src, meaning (unless you were very careful) you’d have to make a separate source code copy for each build
With the CMake method, files are compiled to a separate directory, so it’s easy to build multiple times in separate build folders. The easiest way to track these multiple builds is by (ab?)using the LAMMPS_MACHINE CMake flag to give each executable its own name – of course, designing a clear naming system is your job.
2 Likes
Thank you very much for your reply.
I compile multiple versions of LAMMPS using GNU make in the same /src folder all the time. As long as you don’t have multiple Linux terminal windows trying to build LAMMPS simultaneously, there is no issue. Each build gets its own Obj_* folder in /src, and you can just use make yes-[package] or make no-[package] to toggle packages before compiling.
2 Likes
Yes, you’re right.
Thank you so much.
Please keep in mind that compiling different variants of LAMMPS with the GNU make based build system within the same source checkout can easily lead to inconsistencies and problems as soon as you have packages that require compiling libraries in the lib folder. There are libraries that need to use the same settings as in the main makefile, e.g. for -DLAMMPS_BIGBIG/SMALLBIG/SMALLSMALL, with/without shared library support, with/without MPI support. There you cannot tell the libraries apart from the machine suffix, so those would always need to be cleaned and recompiled. If you need to switch between different ones a lot (like when being a developer/tester having to debug all kinds of problems with LAMMPS versions containing as many packages as possible and compiling with different (cross-)compilers), then this becomes a burden and errors are very easy to make. I have been there and have made mistakes despite my best efforts and thus generally preferred to have multiple git checkouts when the option to compile with CMake didn’t exist.
Using CMake, however, addresses this in the most elegant way, by applying the same settings to compiling source code in the lib folder and in the src folder and compiling everything within a single cmake --build (and being able to use tools like Ninja-build that can parallelize better and more efficiently than GNU make). Since the compilation is completely outside the source tree (it can even be on different file systems) and the configuration settings are stored in the build tree, it is completely safe and reliable.
The only major downside of using CMake I ran into is if you do development and use an older version of LAMMPS: if you add a file or change its dependencies through modifying the list of include statements, you have to rerun cmake in order to update the build files. But for users of CMake 3.12 and later this was addressed recently and now is automatic as well as with GNU make.
2 Likes
I compile LAMMPS nearly every day for different Kokkos options. While Axel’s points are valid, in practice they are not an issue to my workflow. As long as there are separate Makefiles for each machine or configuration then it works just fine for me.