ERROR making LAMMPS Aug 2013 caused by customised pair_airebo.cpp issue

Dear Axel, Steve and all lammps users

This thread is further to my post “Error: Invalid fix style for fix move rotate”. In that thread, it was established that fix move rotate only became available in late 2009 so I need to use a later version of lammps than the May 2009 version I had been using.

I have now tried to install the Aug2013 version of LAMMPs. But this has caused a new problem!

The problem is because we are using a customisation of the pair_airebo.cpp file

Our pair_airebo.cpp file works fine with lammpsMay09 but it appears that changes made since in lammps have caused our potential to be incompatible.

What I would love to know is whether someone can look at the error messages below (that I got while ‘making lammps’) and tell me at what time lammps changed to cause the incompatibility (as I say my pair_airebo.cpp worked fine with the May09 version).

This would save me having to install many versions of lammps since may09 to see which ones work.

Thanks a lot guys

Daniel

This is what I got when I tried to make lammps on our supercomputer (called stoney)

make stoney

make[1]: Entering directory `/ichec/work/uleng018b/lammps-09Aug13_rn/src/Obj_stoney’

mpicxx -O3 -msse3 -axSSE4.2 -DLAMMPS_GZIP -DMPICH_SKIP_MPICXX -DFFT_FFTW -I/ichec/packages/intel/composerxe_mkl/2011.9.293/composer_xe_2011_sp1.9.293/mkl/include/fftw -c …/pair_airebo.cpp

…/pair_airebo.cpp(37): warning #47: incompatible redefinition of macro “MIN” (declared at line 34 of “…/pointers.h”)

#define MIN(a,b) ((a) < (b) ? (a) : (b))

^

…/pair_airebo.cpp(38): warning #47: incompatible redefinition of macro “MAX” (declared at line 35 of “…/pointers.h”)

#define MAX(a,b) ((a) > (b) ? (a) : (b))

^

…/pair_airebo.cpp(99): error: class “LAMMPS_NS::Memory” has no member “destroy_2d_int_array”

memory->destroy_2d_int_array(setflag);

^

…/pair_airebo.cpp(100): error: class “LAMMPS_NS::Memory” has no member “destroy_2d_double_array”

memory->destroy_2d_double_array(cutsq);

^

…/pair_airebo.cpp(101): error: class “LAMMPS_NS::Memory” has no member “destroy_2d_double_array”

memory->destroy_2d_double_array(cutljsq);

^

…/pair_airebo.cpp(102): error: class “LAMMPS_NS::Memory” has no member “destroy_2d_double_array”

memory->destroy_2d_double_array(lj1);

^

…/pair_airebo.cpp(103): error: class “LAMMPS_NS::Memory” has no member “destroy_2d_double_array”

memory->destroy_2d_double_array(lj2);

^

…/pair_airebo.cpp(104): error: class “LAMMPS_NS::Memory” has no member “destroy_2d_double_array”

memory->destroy_2d_double_array(lj3);

^

…/pair_airebo.cpp(105): error: class “LAMMPS_NS::Memory” has no member “destroy_2d_double_array”

memory->destroy_2d_double_array(lj4);

^

…/pair_airebo.cpp(137): error: identifier “virial_compute” is undefined

if (vflag_fdotr) virial_compute();

^

…/pair_airebo.cpp(149): error: class “LAMMPS_NS::Memory” has no member “create_2d_int_array”

setflag = memory->create_2d_int_array(n+1,n+1,“pair:setflag”);

^

…/pair_airebo.cpp(154): error: class “LAMMPS_NS::Memory” has no member “create_2d_double_array”

cutsq = memory->create_2d_double_array(n+1,n+1,“pair:cutsq”);

^

…/pair_airebo.cpp(158): error: class “LAMMPS_NS::Memory” has no member “create_2d_double_array”

cutljsq = memory->create_2d_double_array(2,2,“pair:cutljsq”);

^

…/pair_airebo.cpp(159): error: class “LAMMPS_NS::Memory” has no member “create_2d_double_array”

lj1 = memory->create_2d_double_array(2,2,“pair:lj1”);

^

…/pair_airebo.cpp(160): error: class “LAMMPS_NS::Memory” has no member “create_2d_double_array”

lj2 = memory->create_2d_double_array(2,2,“pair:lj2”);

^

…/pair_airebo.cpp(161): error: class “LAMMPS_NS::Memory” has no member “create_2d_double_array”

lj3 = memory->create_2d_double_array(2,2,“pair:lj3”);

^

…/pair_airebo.cpp(162): error: class “LAMMPS_NS::Memory” has no member “create_2d_double_array”

lj4 = memory->create_2d_double_array(2,2,“pair:lj4”);

^

…/pair_airebo.cpp(196): error #165: too few arguments in function call

error->all(“Incorrect args for pair coefficients”);

^

…/pair_airebo.cpp(201): error #165: too few arguments in function call

error->all(“Incorrect args for pair coefficients”);

^

…/pair_airebo.cpp(214): error #165: too few arguments in function call

} else error->all(“Incorrect args for pair coefficients”);

^

…/pair_airebo.cpp(239): error #165: too few arguments in function call

if (count == 0) error->all(“Incorrect args for pair coefficients”);

^

…/pair_airebo.cpp(249): error #165: too few arguments in function call

error->all(“Pair style AIREBO requires atom IDs”);

^

…/pair_airebo.cpp(251): error #165: too few arguments in function call

error->all(“Pair style AIREBO requires newton pair on”);

^

…/pair_airebo.cpp(279): error #165: too few arguments in function call

if (setflag[i][j] == 0) error->all(“All pair coeffs are not set”);

^

…/pair_airebo.cpp(983): error #165: too few arguments in function call

error->one(“Neighbor list overflow, boost neigh_modify one or page”);

^

…/pair_airebo.cpp(1166): error #165: too few arguments in function call

error->one(“Neighbor list overflow, boost neigh_modify one or page”);

^

…/pair_airebo.cpp(1340): error #165: too few arguments in function call

error->one(“Neighbor list overflow, boost neigh_modify one or page”);

^

…/pair_airebo.cpp(3450): error #165: too few arguments in function call

error->one(str);

^

compilation aborted for …/pair_airebo.cpp (code 2)

make[1]: *** [pair_airebo.o] Error 2

make[1]: Leaving directory `/ichec/work/uleng018b/lammps-09Aug13_rn/src/Obj_stoney’

make: *** [stoney] Error 2

……………………………………………………………………………………………………………

Daniel Mulvihill

Government of Ireland Research Fellow,

Department of Mechanical, Aeronautical, and Biomedical Enginering,

University of Limerick

Just update your copy of pair_airebo.cpp to be compatible

with current LAMMPS. If you look at other pair

styles in LAMMPS and how they do things like
call error->all(), you will find that all (or nearly all) the
changes you need to make are trivial.

Steve

Dear Axel, Steve and all lammps users

This thread is further to my post “Error: Invalid fix style for fix move
rotate”. In that thread, it was established that fix move rotate only
became available in late 2009 so I need to use a later version of lammps
than the May 2009 version I had been using.

I have now tried to install the Aug2013 version of LAMMPs. But this has
caused a new problem!

The problem is because we are using a customisation of the pair_airebo.cpp
file

Our pair_airebo.cpp file works fine with lammpsMay09 but it appears that
changes made since in lammps have caused our potential to be incompatible.

What I would love to know is whether someone can look at the error messages
below (that I got while ‘making lammps’) and tell me at what time lammps
changed to cause the incompatibility (as I say my pair_airebo.cpp worked
fine with the May09 version).
This would save me having to install many versions of lammps since may09 to
see which ones work.

a) the information that you are looking for can be trivially obtained
through checking out the lammps sources via either subversion or git
and use the integrated tools to track down changes.

b) the changes required are trivial and can be easily inferred from
comparing your version of airebo with the canonical one.

c) it is *strongly* recommended to rename your pair style class and
its pair style name (say to PairAIREBOMOD and airebo/mod), so you can
have the original and the modified version side by side and will not
run into any problems due confusing the canonical version with the
modified version.

axel.

Thanks Steve and Axel,

I know that updating the .cpp file is one option (the most advisable one
too) but given that I have no knowledge of C++ or lammps potential
files, this could be difficult and mostly take a lot of time.
I know that our .cpp was created in Aug 2010. And Aug2010 also has 'fix
move rotate' so I should be ok with a version in 2010.

Would ye be able to guess at what date (roughly) the changes were made
in lammps that caused the incompatibility? As I would like to use as new
a version as I can.
Just a rough guess would be very useful

Daniel

Thanks Steve and Axel,

I know that updating the .cpp file is one option (the most advisable one
too) but given that I have no knowledge of C++ or lammps potential
files, this could be difficult and mostly take a lot of time.

nonsense. any person with little knowledge in C++ can do that. it is
very dangerous to make estimates without knowing the topic. and
teaching yourself the skill to be able to do such modifications would
be a addition of significant value to your skillset. being a
computational scientist without any knowledge to do even minimal
modifications or at least being able to assess what is a small or a
large task will put you at the mercy of your colleagues. in the
current competitive climate they *will* take advantage of that (and
thus you). by that token it is almost a necessity to learn how to do
this by yourself.

in addition there is a very simple and clean way to solve your problem:

document the modifications and contribute the modified file to the
LAMMPS distribution. steve will stick it into the USER-MISC package
and i'd be happy to sort out the compilation and renaming issue. and
then you will have a version that will always compile in the future
with the latest release of LAMMPS.

I know that our .cpp was created in Aug 2010. And Aug2010 also has 'fix
move rotate' so I should be ok with a version in 2010.

that is a *very* shortsighted idea. next week you will discover that
the aug2010 version is missing a feature that you want to use, not to
mention all the bugfixes and performance improvements that were added
to lammps since and will be done in the future. considering that we
had a steady influx of bugfixes and improvements and practically no
significant changes to the lowlevel framework over the last years,
there is hardly a reason not to use the very latest version.

Would ye be able to guess at what date (roughly) the changes were made
in lammps that caused the incompatibility? As I would like to use as new
a version as I can.
Just a rough guess would be very useful

see for yourself:

[email protected]... lammps-icms]$ git blame src/error.h
0f4a27ad (Axel Kohlmeyer 2011-12-23 18:27:40 -0500 1) /* -*- c++ -*-

Dear Axel and Steve,

For our custom pair_airebo potential, I found that I was able to make
lammps for versions upto and including the 10 Mar 2011 (later versions
gave a list or errors).
I got the lmp file so I thought the problem was solved.
However, when I run my .in file I get the error "invalid pair style"
under the line pair_style airebo 0 0 0

What I did was to replace the pair_airebo.cpp and pair_airebo.h files
in the src folder with our ones and then make lammps.

I also have a CH.airebo in the current directory.

Did I miss a step. For some reason it looks like lammps is not
recognising the potential

Thanks guys

Daniel

daniel,

since you keep going against the advice you are given, you are on your own.

axel.

Axel,

I know, your suggestion is the optimum. I guess we are looking for a
quick fix due to time constraints really. We don't need many featues of
lammps I think. If we have fix move rotate and can use the custom
potential we would be ok.

Daniel

Axel,

I know, your suggestion is the optimum. I guess we are looking for a

not the optimum. but the reasonable choice.

the optimum would be to fully port your modifications to the current
version of airebo. which contains several corrections and bugfixes and
also *massive* performance enhancements (up to a factor of two for
certain cases). thus depending on what kind of simulation resources
you have available to you and what effort it takes, that may actually
make that effort "pay" for itself.

quick fix due to time constraints really. We don't need many featues of
lammps I think. If we have fix move rotate and can use the custom
potential we would be ok.

but you will knowingly include *all* the bugs that have been found and
fixed since. as i stated, there are several reasons why your approach
is not a good choice, and the issues that keep your code from
compiling with a current version of LAMMPS are easy to solve.

what use is a fast result if you know that there are problems?

axel.