Compiling options change output of dreiding example

LAMMPS (3 Mar 2020)

Dear LAMMPS developers,

building a lammps executable with the makefiles provided in MAKE/OPTIONS for intel cpus,

I observed a weird behaviour when I ran the lammps example for the dreiding forcefield with such executable.

The example finishes within 100 steps, but when I use 1000 steps, I get the error “out of range atoms”.

For the compilation of my executable (mylmp), I set up my own Makefile, taking the Makefiles for Intel CPUs in MAKE/OPTIONS as a guideline.

The Makefile contains the following options.

CC = mpiicpc

OPTFLAGS = -O2 -xHost -fp-model fast=2 -no-prec-div -qoverride-limits -qopt-zmm-usage=high

CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -qno-offload -fno-alias -ansi-alias \




LINK = mpiicpc

LINKFLAGS = -g -O2 -qopenmp (OPTFLAGS) -L(MKLROOT)/lib/intel64/

LIB = -ltbbmalloc -lmkl_intel_ilp64 -lmkl_sequential -lmkl_core

SIZE = size

As a test, I compiled a second executable (lmp_mpi) with the Makefile.mpi, which is already provided in lammps.

With this new executable, the dreiding example finishes normally within 1000 steps and no errors occur.

However, another weird thing is that now the energies I get from the calculation are completely different than the ones I get with my first executable:


---------------- Step 220 ----- CPU = 0.4412 (sec) ----------------
TotEng = 2068.061250 KinEng = 403.371456 Temp = 353.323145
PotEng = 1664.689794 E_bond = 365.884256 E_angle = 357.263851
E_dihed = 6.364345 E_impro = 0.000000 E_vdwl = 1091.384109
E_coul = 205.774355 E_long = -361.981122 v_E_hbond = -64.726362
v_C_hbond = 238.000000 Press = 29817.503028 Volume = 7447.236335
ERROR on proc 0: Out of range atoms - cannot compute PPPM (…/pppm.cpp:1940)
Last command: run 1000


---------------- Step 1000 ----- CPU = 5.7260 (sec) ----------------
TotEng = 111.883787 KinEng = 67.415958 Temp = 59.051324
PotEng = 44.467828 E_bond = 1.314077 E_angle = 1.975047
E_dihed = 3.725510 E_impro = 0.000000 E_vdwl = -158.657992
E_coul = 557.874851 E_long = -361.763666 v_E_hbond = -115.730814
v_C_hbond = 261.000000 Press = -268.853589 Volume = 7447.236335

Note the difference in vdw, angle, coulomb, etc.

I thought it was a problem of some installed package, but it seems that it is independent of the installed packages.

After deleting and adding some of the options I have added to my Makefile, I found that $(OPTFLAGS) in the CCFLAGS variable was the one,

which screws this up (or at least it seems to me like that), meaning that if I remove $(OPTFLAGS) from CCFLAGS and recompile the executable,

I can run the dreiding example without error, and I get the same energies as with lmp_mpi.

Furthermore, I tried to add individual options from OPTFLAGS to CCFLAGS, to see, if one specific option is the trigger.

But just adding ‘-O2’ to CCFLAGS already results in the failure of the dreiding example as described above.

I wanted to ask, if someone knows of this problem or has come across it? I’m not sure what I’m doing wrong here or what I’m missing,

since the code compiles fine.

I also used the mylmp executable to do reaxff simulations previously and did not come across any problems with energies or “out of range” errors.

Should I not use Makefile.intel_cpu* to build an executable?

I have not tested any other provided examples, since I wanted to be sure that I can reproduce the behaviour.

As a side note: this is also independent of the user-intel package, i.e., it does not make a difference, if this package is installed or not, I can still reproduce this behaviour by adding/removing $(OPTFLAGS) from CCFLAGS.

Best regards,

Paul Schwarz

Yes, this kind of thing is known to happen.
Certain versions of the Intel compiler are known to miscompile LAMMPS
with high optimization levels.
and some parts of LAMMPS are programmed in a more aggressive style
than others, which makes this more likely.
Sometimes there is also a bug in the code that data is not
initialized. Which would be undetected sometimes because the allocated
storage is usually initialized to zero. But some compilers do
different memory management and then that may cause


Ok, I was not aware of this.
Thanks for the info.


Hi Paul,

The “fno-alias” flag has been removed from the Intel makefiles (and should no longer be there in the Mar 2020 version).

This has been an issue before:


  • Mike

Hello Mike,

thanks for pointing that out.

I’m not sure how this option got into my Makefile, but after removing it I can run the dreiding example.