Hi All,
I have been trying to build and run lammps from an M1 Mac for months now with limited success. I am able to run example scripts using a version of lammps installed through homebrew with no problems, however I have not been able to figure out a way to download the USER-REAXC package through homebrew, which led me to the next method of lammps installation: from tarball. I downloaded the most recent version (29 Oct 2020) from the lammps site and followed the rest of the installation steps (from the site) exactly. The “make yes-USER-REAXC” command works just fine, the issue arrises when I attempt to “Make” serial and mpi as I get the following errors:
[/uploads/default/original/2X/4/4414d307a6d1871404fbb381a72ed63cf03a1cf6.png]
I figured the “unrecognized architecture” error was referencing the M1 ARM chip, so I used “make aarch64_arm_serial_armpl” instead (from the MACHINES directory), which resulted in more errors:[/uploads/default/original/2X/b/b7136dabe06ad50644ac069dd57d9fa070b1422c.png]
I’ve tried looking up the errors and have had no luck. Please let me know if you have any experience with building lammps on an ARM chip, or installing packages with homebrew on Macs. Thank you in advance.
Please note I’m very new to lammps and have attempted to exhaust all of google before asking here. Apologies in advance if this is trivial.
Best,
Kimia
those screenshot images are unreadable and thus useless. it is better to
use cut-n-paste and text anyway. *much* easier to read and *much* smaller.
you much have missed the most obvious alternative to try out: build LAMMPS
using the CMake build system.
using traditional make files (like you did) requires adapting those files
to (unusual) new platforms and for that you have to make certain your tools
work and you use the correct settings, which is knowledge that is not as
common these days than it was when LAMMPS was started many, many years ago.
with CMake many of the system specific settings are encoded into the cmake
executable or detected automatically during the cmake configuration step
and then - by default - the (best) available native compilers are used.
another option would be to look into how to customize the homebrew build
process to include more packages (something you need to ask in the
corresponding forum(s)).
axel.
Dr. Axel Kohlmeyer,
Thank you for taking the time to reply to my inquiry about building LAMMPS. I followed your suggestion to use CMake instead of traditional Make, and after running the cmake ../cmake command from the LAMMPS manual<https://lammps.sandia.gov/doc/Build_cmake.html>, it gives me the following error:
(base) kimiaghaffari@MacBook-Air-2 build % cmake ../cmake
-- The CXX compiler identification is AppleClang 12.0.0.12000032
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ - broken
CMake Error at /Applications/CMake.app/Contents/share/cmake-3.19/Modules/CMakeTestCXXCompiler.cmake:59 (message):
The C++ compiler
"/Library/Developer/CommandLineTools/usr/bin/c++"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /usr/local/Cellar/lammps-29Oct20/build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make cmTC_4d6a1/fast && /Library/Developer/CommandLineTools/usr/bin/make -f CMakeFiles/cmTC_4d6a1.dir/build.make CMakeFiles/cmTC_4d6a1.dir/build
Building CXX object CMakeFiles/cmTC_4d6a1.dir/testCXXCompiler.cxx.o
/Library/Developer/CommandLineTools/usr/bin/c++ -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -o CMakeFiles/cmTC_4d6a1.dir/testCXXCompiler.cxx.o -c /usr/local/Cellar/lammps-29Oct20/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
Linking CXX executable cmTC_4d6a1
/Applications/CMake.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/cmTC_4d6a1.dir/link.txt --verbose=1
/Library/Developer/CommandLineTools/usr/bin/c++ -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/cmTC_4d6a1.dir/testCXXCompiler.cxx.o -o cmTC_4d6a1
ld: warning: ignoring file /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libc++.tbd, missing required architecture arm64 in file /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libc++.tbd
ld: warning: ignoring file /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd, missing required architecture arm64 in file /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd
ld: dynamic main executables must link with libSystem.dylib for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [cmTC_4d6a1] Error 1
make: *** [cmTC_4d6a1/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:12 (project)
-- Configuring incomplete, errors occurred!
See also "/usr/local/Cellar/lammps-29Oct20/build/CMakeFiles/CMakeOutput.log".
See also "/usr/local/Cellar/lammps-29Oct20/build/CMakeFiles/CMakeError.log".
I’m not sure what the cause is but I once again see mention of unrecognized architecture, which is what I think may be the issue. Please let me know if you have any potential solutions. In the mean time I will keep looking into ways to customize Homebrew to allow for new packages.
Best,
Kimia
this confirms what I was suspecting before: it looks like your default
compiler is not able to compile anything correctly.
either additional settings/flags are required or something else is broken
that is impossible to tell from remote.
if CMake says that it cannot detect the architecture, then that means that
your CMake installation is not fully working either.
there is little that can be done for that from our side under these
circumstances, since we don't have access to that hardware here.
if somebody would be willing to donate an M1 architecture based mac mini to
the HPC team at Temple University, we can look into sorting out potential
issues and/or providing suitable configuration files and/or reporting
problems to upstream projects.
but it is not possible to do this from remote or to tell if you have a
system where compilation is supposed to work, or whether it is
misconfigured or otherwise broken.
since you are running on a *very* new architecture, expecting open source
software to simply work is - to put it mildly - quite optimistic.
axel.