I have installed LAMMPS with MPI on various Macs running OS 10.6 and 10.7 using Homebrew, but I just bought another one running OS 10.8.4, and have run into a problem I can't figure out how to solve. It makes LAMMPS ok, except when I try to make it with MPI. In that case, it throws this error:
==> make -f Makefile.gfortran
a - reax_lammps.o
a - reax_poten.o
a - reax_reac.o
a - reax_charges.o
make: *** [lib] Error 1
I've tried all the advice I can on the Homebrew troubleshooting page, and I've tried uninstalling, then reinstalling gfortran, all with the same result.
Can anyone suggest what I ought to try next, or at least help me translate the error message?
Thanks,
Barry Bickmore
Looks to me that your problem is compiling the reax library and not installing Lammps per se.
Carlos
This error report does not look complete. The "a - " lines are from
'ar' which creates libreax.a at the end of the build process.
- check if there are more error messages
- check if all the *.o files needed for libreax.a are built
- check if the ar command returns an error code
This has nothing to do with MPI. Or the homebrew tool.
Check lib/reax/Makefile.gfortran.
Its EXTRAMAKE variable points to a non-existing file. Most likely it should be Makefile.lammps.gfortran.
That being said, there is no more need to even compile this library, and the REAX package, since it has been superseded by the USER-REAXC package.
Axel
Hi Axel,
I am a novice in the mysteries of the Makefile, so I appreciate your help.
- I checked in the Makefile.gfortran file, and EXTRAMAKE is, indeed, set to Makefile.lammps.gfortran. This file does exist in the same directory, and its contents are the same as in a previous version (21Nov12) that Homebrew managed to compile with MPI on another Mac running OS 10.7. The contents of Makefile.lammps.gfortran are pretty sparse, though. Here they are:
Settings that the LAMMPS build will import when this package library is used
reax_SYSINC =
reax_SYSLIB = -lgfortran
reax_SYSPATH =
- Until I manage to understand makefiles better, I probably need to stick with Homebrew. Any idea how I could make Homebrew compile without Reax? I looked up the Ruby file that Homebrew apparently uses, and even though I’ve never programmed in Ruby, it looks like it would be pretty simple to modify it so as to exclude Reax. Homebrew downloads the Ruby file from the online repository, though, so I can’t change that. Would it work to copy the Ruby file, modify it, and then run it independently of Homebrew?
Thanks,
Barry
Homebrew wants to install the 14May13 version of LAMMPS,
I don't use macos and don't use homebrew either. I suggest you contact the author/maintainer of those scripts to resolve those issues or you teach yourself how to compile LAMMPS manually.
Axel
I did contact the author/maintainer of the homebrew script, and he was very helpful, so I thought I would give the gist of his answer for the archives. (I know of at least one other person who has run into this issue.) He said that his guess was that the Homebrew MPI installation had gotten a bug in it, and I might be able to get around it by typing this in the Terminal:
MPIFC=(brew --prefix)/bin/mpif90 MPICXX=(brew --prefix)/bin/mpic++ brew install lammps --with-mpi
This worked, but he says he will try to get the MPI issue fixed in the near future.
Thanks for your help,
Barry
I did contact the author/maintainer of the homebrew script, and he was very
helpful, so I thought I would give the gist of his answer for the archives.
that is great. both, that you got your problem fix *and* that you're
sharing how it was resolved.
(I know of at least one other person who has run into this issue.) He said
that his guess was that the Homebrew MPI installation had gotten a bug in
yeah, this is why i am suspicious of these kind of automated build
systems. there also is gentoo linux or the BSD "ports" and others.
they are quite fragile, and this is why i'd rather go something based
on pre-compiled binaries like .rpm or .deb packages. this puts more of
a burden on the package maintainer, but you also get to see as the
"provider" whether your efforts work. just set something like that up
for rpm packages, so i been through this first hand. a user has to
deliberately violate the package dependency resolution to break such a
packaging system. the downside is lack of flexibility, course. but i
figure, somebody that does want the flexibility, can compile with the
regular make system of LAMMPS. it is no rocket science and LAMMPS as
an application is fairly easygoing in terms of external dependencies
(aka "dependency hell").
in any case, good luck with your simulations,
axel.