I’d like to ask whether Linux ARM64 is an officially supported architecture ?
The only mentioning of ARM64 (ARM v8) at the website I was able to find is at https://www.lammps.org/abstracts/abstract.19271.html
I see that the project uses GitHub Actions as a CI - Actions · lammps/lammps · GitHub.
But at the moment GitHub Actions supports only x86_64. Is there another (maybe internal) CI used for testing on other architectures ?
We currently don’t do integration or unit testing on ARM64 due to lack of suitable hardware. For that same reason we do testing via GitHub Actions on MacOS.
But LAMMPS is very portable and should also run on that platform. If you look in the conventional build system makefiles, you should see some mention of ARM64 platforms that LAMMPS has been compiled on in the past (those makefiles have been in the distribution for quite a while).
Thanks for the quick answer, @akohlmey !
I work for https://openlabtesting.org and we are willing to donate an ARM64 VM for long-term usage.
GitHub Actions could build on Linux ARM64 but only as a self-hosted runner. The problem is that self-hosted runners are not recommended for public repositories due to security related issues.
Another way to build on ARM64 with GitHub Actions is by delegating to a remote Kubernetes cluster. I have explained how to do it at GithubActions: Build and test on HuaweiCloud ARM64 | by Martin Grigorov | Medium.
If you are interested then please contact me at martin.grigorov @ gmail dot com to discuss further the preferred Linux distro, hardware specs, etc.
Thanks for the offer. I will discuss this with my colleague @rberger who manages the LAMMPS CI environment and he may get back to you asking for details. Not sure if this is really needed, since most portability issues so far have been between different compilers (GNU vs. Clang vs. Apple vs. PGI/Nvidia vs. Cray) and different operating systems (Linux vs. macOS vs. Windows vs. FreeBSD). Based on previous experience it will be easier to have local hardware, so we have already been considering, e.g., to get an ARM based Mac mini as there is a substantial user base of people using or developing LAMMPS on macOS.
FYI, we are doing most of the testing on some recycled HPC hardware (mostly quad socket AMD Opterons with plenty of cores and RAM) with Jenkins ( https://ci.lammps.org/ ). Since we are testing multiple build systems with different compilers, Linux flavors and compilation settings, it can create quite a significant workload, particularly for compilation and unit tests, since those tests are run for every update to pull requests.
Hi @akohlmey and @rberger !
I just wanted to check whether you did have a chance to discuss this ?
A linux/arm64 node would fit nicely next to the amd64 and ppc64le ones at Nodes [Jenkins] !
Yes, but there are next to no benefits (how are the compilers and OS significantly different from other Linux variants?) and a whole bunch of security issues (all our execution hosts are in a local network) having to use an external machine.
If you want to have automated testing you can just set up such the VM to regularly pull the latest master brach from GitHub and then compile and run the unit tests (or other tests, all our test scripts and files are in the lammps-testing repository) from CMake / Ctest and file an issue or contact us via the LAMMPS developer Slack (or email or here in the LAMMPS Development sub-category) if something is broken that is not also broken for other tests.
@mgrigorov We should be getting ARM64 hardware (MacMini M1) in the next weeks, which I’ll integrate into our testing infrastructure. My plan is to add it as MacOS ARM box and possibly add a QEMU aarch64 Linux VM in there. This isn’t the same as saying we’re officially supporting it, but we’re making small steps to improve support and testing. Anyway, thanks for the offer!
Have we already have arm64 CI now (or some other way to protect it)? We are plan to use lammps on the server with aarch64 Linux arch, so we are concerned about the stability of lammps in aarh64.
LAMMPS is very portable in terms of CPUs. Portability concerns are mostly about operating systems (and changing APIs like Apple’s software engineers seem to enjoy doing), standards compliance and stability of compilers and portability and performance of low-level libraries (like the communication layers that MPI is using). The major difference that you will be seeing when migrating e.g. from x86_64 to aarch64 should be due to the different implementation of the floating point math hardware and specifically the math library implementation and optimizations(!!).
Neither of those issues is something that the LAMMPS developers can do anything about.
We do run tests on an M1 CPU MacMini: cmake_mpi_openmp_smallbig_clang_shared [dev » develop » macos_arm64 » unit_tests] [Jenkins]
The recorded test failures in recent tests are due to minor numerical differences that are acceptable and currently affect just one test out of over 500.