fix imd compilation error

Dear LAMMPS users,

I try to compile the most recent LAMMPS version on my machine (Mac OS X 10.6.8), and I get the following error:

mpic++ -O -MMD -DLAMMPS_GZIP -I../../lib/atc -I../../lib/reax -I../../lib/poems -I../../lib/meam -DOMPI_SKIP_MPICXX -DFFT_FFTW -I/sw/include -c fix_imd.cpp
fix_imd.cpp: In function ‘void* imdsock_accept(void*)’:
fix_imd.cpp:1246:76: error: invalid conversion from ‘int*’ to ‘socklen_t*’
fix_imd.cpp:1246:76: error: initializing argument 3 of ‘int accept(int, sockaddr*, socklen_t*)’
make[1]: *** [fix_imd.o] Error 1
make: *** [mac_mpi] Error 2

This only occurs when the USER-MISC package is included, obviously.

Also, when I try to include packages using e.g. "make yes-standard", I tend to get the following error, which I have not seen before:

sed: 1: "../Makefile.package.set ...": invalid command code .

Any ideas about how to fix this?

Finally, when trying to include any package using gfortran, I get a lot(!) of errors at the very end of the compilation process related to fortran, so I guess it is not linking correctly. I know there has been some restructuring of makefiles lately, and I have been using my own (slightly modified) makefile where I have specified reax_SYSLIB and reax_SYSPATH. These lines are now gone from the makefiles in the src/MAKE folder - where would be the right place to specify this instead?

Sincerely,
Christer H. Ersland.

I don't see the IMD error, with either g++ or the Intel compiler.
I don't see any error with make-yes-standard.
Are you using the most current version of LAMMPS?

Re: the fortran settings. Those are now pulled into the
LAMMPS build from a Makefile.lammps file in each lib dir.
E.g. lammps/lib/meam/Makefile.lammps.

When you build the lib, you should insure those settings
are correct for the LAMMPS build.

Steve

Dear LAMMPS users,

I try to compile the most recent LAMMPS version on my machine (Mac OS X 10.6.8), and I get the following error:

mpic++ -O -MMD -DLAMMPS_GZIP -I../../lib/atc -I../../lib/reax -I../../lib/poems -I../../lib/meam -DOMPI_SKIP_MPICXX -DFFT_FFTW -I/sw/include -c fix_imd.cpp
fix_imd.cpp: In function ‘void* imdsock_accept(void*)’:
fix_imd.cpp:1246:76: error: invalid conversion from ‘int*’ to ‘socklen_t*’
fix_imd.cpp:1246:76: error: initializing argument 3 of ‘int accept(int, sockaddr*, socklen_t*)’
make[1]: *** [fix_imd.o] Error 1
make: *** [mac_mpi] Error 2

This only occurs when the USER-MISC package is included, obviously.

Also, when I try to include packages using e.g. "make yes-standard", I tend to get the following error, which I have not seen before:

can you try compiling using the -fpermissive flag.

this piece of code has been written for and compiled on _many_
different platforms, and i am surprised that macos's compilers
suddenly start barking at it. i will make some inquiries.

if using -fpermissive doesn't help, then just remove fix_imd.cpp and
fix_imd.h for now (unless you really need that feature, in that case,
please let me know, and i'll have a closer look soon).

axel.

Hi, and thanks to Axel and Steve for their help.

I tried compiling again using the -fpermissive flag, and it removed the errors in connection to the fix_imd files. Great!

I still get this message when typing "make yes-[package]":
sed: 1: "../Makefile.package.set ...": invalid command code .
and I have no idea why.

I have tried going through the Makefile.lammps and Makefile.lammps.gfortran files in the lib/meam, lib/reax and lib/atc folders, but I still get a long list of errors at the very end of my compilation. The beginning of it looks like this:
Undefined symbols:
  "__gfortran_st_open", referenced from:
      _readtraj_ in libreax.a(reax_inout.o)
      _dipmom_ in libreax.a(reax_inout.o)
      _readaddmol_ in libreax.a(reax_inout.o)
      _readaddmol_ in libreax.a(reax_inout.o)
      _readereg_ in libreax.a(reax_inout.o)
      _readvreg_ in libreax.a(reax_inout.o)
      _readtreg_ in libreax.a(reax_inout.o)
      _readbgf_ in libreax.a(reax_inout.o)
      _readdelphi_ in libreax.a(reax_inout.o)
      _outint_ in libreax.a(reax_inout.o)
      _ffinpt_ in libreax.a(reax_inout.o)
  "__gfortran_st_read", referenced from:
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _readtraj_ in libreax.a(reax_inout.o)
      _stranal_ in libreax.a(reax_inout.o)
      _readaddmol_ in libreax.a(reax_inout.o)

and this continues much longer.
I use the exact same path for the gfortran as I used before.

Also, if I remove reax and instead try with the user-atc package, I get this:
Undefined symbols:
  "_dlange_", referenced from:
      inv(Matrix<double> const&) in libatc.a(Matrix.o)
  "_dgemm_", referenced from:
      MultAB(Matrix<double> const&, Matrix<double> const&, DenseMatrix<double>&, bool, bool, double, double) in libatc.a(Matrix.o)
  "LAMMPS_NS::Modify::add_compute(int, char**)", referenced from:
      ATC::LammpsInterface::atomPE_create() in libatc.a(LammpsInterface.o)
     (maybe you meant: LAMMPS_NS::Modify::add_compute(int, char**, char*))
  "_dgecon_", referenced from:
      inv(Matrix<double> const&) in libatc.a(Matrix.o)
  "_dgetrf_", referenced from:
      inv(Matrix<double> const&) in libatc.a(Matrix.o)
      det(Matrix<double> const&) in libatc.a(Matrix.o)
  "_dgetri_", referenced from:
      inv(Matrix<double> const&) in libatc.a(Matrix.o)
      inv(Matrix<double> const&) in libatc.a(Matrix.o)

With the meam package, I get this (and much more):
Undefined symbols:
  "__gfortran_runtime_error_at", referenced from:
      _compute_pair_meam_ in libmeam.a(meam_setup_done.o)
      _compute_pair_meam_ in libmeam.a(meam_setup_done.o)
      _compute_pair_meam_ in libmeam.a(meam_setup_done.o)
      _compute_pair_meam_ in libmeam.a(meam_setup_done.o)
      _compute_pair_meam_ in libmeam.a(meam_setup_done.o)
      _compute_pair_meam_ in libmeam.a(meam_setup_done.o)
      _compute_pair_meam_ in libmeam.a(meam_setup_done.o)
      _compute_pair_meam_ in libmeam.a(meam_setup_done.o)
  "__gfortran_runtime_error", referenced from:
      _compute_pair_meam_ in libmeam.a(meam_setup_done.o)

In order to investigate this more closely, I tried to start with a fresh version of lib/meam from the newest LAMMPS version. Without any changes in any makefile, it gives an error. When I change lib/meam/Makefile.lammps.gfortran like this (same settings as I used to have in my Makefile.mac_mpi), I still get an error:
meam_SYSLIB = -lgfortran
meam_SYSPATH = -L/sw/lib/gcc4.4/lib
I also tried to do the same change in lib/meam/Makefile.lammps, with the same result.
Finally, I tried to do some changes in lib/meam/Makefile.gfortran:
LINK = mpic++
(used to be g++)
This did also not remove the error message...

Is it something fundamental I have missed here, or is it some other place I should change some settings too/instead? I assume the problems with both meam and reax will disappear if I find out how to set this up properly. The error with the user-atc package, however, should not be gfortran-related. Should I edit the LINK= and CC= in the lib/atc/Makefile.g++ so that they are the same as in my src/MAKE/Makefile.mac_mpi, or should I leave them as they are?

Thanks again for your help!

Sincerely,
Christer H. Ersland

I have tried going through the Makefile.lammps and Makefile.lammps.gfortran files in the lib/meam, lib/reax and lib/atc folders, but I still get a long list of errors at the very end of my compilation. The beginning of it looks like this:
Undefined symbols:
"__gfortran_st_open", referenced from:
_readtraj_ in libreax.a(reax_inout.o)

[...]

and this continues much longer.
I use the exact same path for the gfortran as I used before.

yes, but if you update to a newer version, you should always
have a look at what the recent changes were. check out the
patch of 19 Aug here: http://lammps.sandia.gov/bug.html

the changes the location where you have to specify -lgfortran
to a Makefile.lammps _inside_ the individual lib directories.

Also, if I remove reax and instead try with the user-atc package, I get this:
Undefined symbols:
"_dlange_", referenced from:
inv(Matrix<double> const&) in libatc.a(Matrix.o)
"_dgemm_", referenced from:

yes. that is because atc depends on BLAS/LAPACK. check out
the manual and remember to add your local library to lib/atc/Makefile.lammps

[...]

With the meam package, I get this (and much more):
Undefined symbols:
"__gfortran_runtime_error_at", referenced from:
_compute_pair_meam_ in libmeam.a(meam_setup_done.o)
_compute_pair_meam_ in libmeam.a(meam_setup_done.o)
_compute_pair_meam_ in libmeam.a(meam_setup_done.o)
_compute_pair_meam_ in libmeam.a(meam_setup_done.o)
_compute_pair_meam_ in libmeam.a(meam_setup_done.o)
_compute_pair_meam_ in libmeam.a(meam_setup_done.o)
_compute_pair_meam_ in libmeam.a(meam_setup_done.o)
_compute_pair_meam_ in libmeam.a(meam_setup_done.o)
"__gfortran_runtime_error", referenced from:
_compute_pair_meam_ in libmeam.a(meam_setup_done.o)

again, calls to libgfortran are undefined, which means that -lgfortran
is not found. the reason for it was explained above.

In order to investigate this more closely, I tried to start with a fresh version of lib/meam from the newest LAMMPS version. Without any changes in any makefile, it gives an error. When I change lib/meam/Makefile.lammps.gfortran like this (same settings as I used to have in my Makefile.mac_mpi), I still get an error:

you obviously have to copy the file to lib/meam/Makefile.lammps

meam_SYSLIB = -lgfortran
meam_SYSPATH = -L/sw/lib/gcc4.4/lib
I also tried to do the same change in lib/meam/Makefile.lammps, with the same result.
Finally, I tried to do some changes in lib/meam/Makefile.gfortran:
LINK = mpic++
(used to be g++)
This did also not remove the error message...

there is no linking done when compiling in lib/mean.

Is it something fundamental I have missed here, or is it some other place I should change some settings too/instead? I assume the problems with both meam and reax will disappear if I find out how to set this up properly. The error with the user-atc package, however, should not be gfortran-related. Should I edit the LINK= and CC= in the lib/atc/Makefile.g++ so that they are the same as in my src/MAKE/Makefile.mac_mpi, or should I leave them as they are?

yes. see explanation above.

i can only re-iterate. if you stay current with lammps you have
to keep an eye on what is happening.

cheers,
    axel.

Hi Axel,

I try to keep up-to-date with changes in new versions of LAMMPS, so I _did_ know that I had to specify -lgfortran etc. inside the Makefile.lammps files inside the lib folders. This is what I did from the start, but as I explained, it did not work.

I also mentioned the strange errors I got when trying to add new packages typing e.g. "make yes-standard", "make yes-meam". When typing these commands, I got:
$ make yes-meam
Installing package meam
sed: 1: "../Makefile.package.set ...": invalid command code .
So something is a bit wrong when trying to add new packages.

Today I had a look at the file Makefile.package inside the /src directory, and noticed that things like -lgfortran and the path to the gfortran library had _not_ been added to this file. I tried to manually enter -lgfortran (for reax and meam) and -lblas and -llapack (for user-atc) in the PKG_SYSLIB line of this file. I also added the path to the gfortran library to the PKG_SYSPATH line, and compiled LAMMPS again. Now everything worked just fine! LAMMPS compiles, and I can run various examples without error (even from the meam and reax folders).
My conclusion would have to be that the variables given in the Makefile.lammps files in the individual lib directories are not properly communicated to the Makefile.package file. This might have something to do with the above error?

To me it looks like something is not working exactly as intended when adding packages, and that this results in libraries and paths not being communicated to LAMMPS via the Makefile.package file. Could it be something with my shell that result in this error, or is something just wrong in this process? (I am by no means a Unix expert - I mostly do this by trial and error - so I am just trying some semi-qualified guessing here.)

Thanks for your help, and I hope you could give some more comments/solutions to this.

Sincerely
Christer H. Ersland.

Comments below.

Steve

Hi Axel,

I try to keep up-to-date with changes in new versions of LAMMPS, so I _did_ know that I had to specify -lgfortran etc. inside the Makefile.lammps files inside the lib folders. This is what I did from the start, but as I explained, it did not work.

I also mentioned the strange errors I got when trying to add new packages typing e.g. "make yes-standard", "make yes-meam". When typing these commands, I got:
$ make yes-meam
Installing package meam
sed: 1: "../Makefile.package.set ...": invalid command code .
So something is a bit wrong when trying to add new packages.

If I could re-produce this error, I could help, but I cannot.

Today I had a look at the file Makefile.package inside the /src directory, and noticed that things like -lgfortran and the path to the gfortran library had _not_ been added to this file. I tried to manually enter -lgfortran (for reax and meam) and -lblas and -llapack (for user-atc) in the PKG_SYSLIB line of this file. I also added the path to the gfortran library to the PKG_SYSPATH line, and compiled LAMMPS again. Now everything worked just fine! LAMMPS compiles, and I can run various examples without error (even from the meam and reax folders).
My conclusion would have to be that the variables given in the Makefile.lammps files in the individual lib directories are not properly communicated to the Makefile.package file. This might have something to do with the above error?

No - you should not edit the src/Makefile.package at all. Setting
like -lgfortran and -lblas
do not go in that file. They go in the lib/blah/Makefile.lammps file
for the specific
packate that needs them. In your previous email I think you said you
added -lgfortran
to the lib/meam/Makefile.lammps file, which is correct. But you got
an error that
the the gfortran lib could not be found. Which simply means that you
also have to
specify a -L setting for the SYSPATH in the same file.

Makefile.package is auto-edited when you include/exclude packages, so
your changes will
be lost or persist when they shouldn't.

Every lo-level Makefile in LAMMPS now has these lines:

include Makefile.package.settings
include Makefile.package

The "settings" file will include the lib/blah/Makefile.lammps for packages you
have installed, like meam.