Problem with intel lrt yes and minimize

Dear LAMMPS developers,

my colleague and i ran in the problem that as soon we are using intel package with the option "lrt yes" that the minimization (min_style cg) does not work properly.

I can reproduce the behavior with a modified version of the example script "in.phosphate" (see below for the script, commands, lammps-version).

As soon as we are not using "lrt yes" the minimization takes place correctly.
"-sf intel -pk intel 0 omp 1 mode double lrt yes" <= no minimizations steps
"-sf intel -pk intel 0 omp 1 mode double" <= OK
"" <= OK

I looked through the Documentation but couldn't find any restrictions for the combination of "-sf intel -pk intel 0 omp 1 lrt yes" and "minimize".
So it might be an error or something one should warn about, if you could confirm that there is no user-error on my side and you can reproduce the behavior i can write an issue on github.

Sincerely,
Michael King

Note:
There is a small different between icc-2017 and icc-2018 in "mode mixed".

# Testsystem
# \{LAMMPSFOLDER\}/examples/accelerate/data\.phosphate \# {LAMMPSFOLDER}/examples/accelerate/in.phosphate (modified, see below)

variable x index 1
variable y index 1
variable z index 1
variable t index 100

units metal
atom_style charge

read_data data.phosphate

replicate $x $y $z

pair_style lj/cut/coul/long 15.0

pair_coeff 1 1 0.0 0.29
pair_coeff 1 2 0.0 0.29
pair_coeff 1 3 0.000668 2.5738064
pair_coeff 2 2 0.0 0.29
pair_coeff 2 3 0.004251 1.91988674
pair_coeff 3 3 0.012185 2.91706967

kspace_style pppm 1e-5

neighbor 2.0 bin
fill in a
thermo 100
timestep 0.001

min_style cg
min_modify line quadratic
minimize 1e-6 1e-6 100 100

# LAMMPS
LAMMPS (16 Mar 2018) & LAMMPS (11 May 2018)

make yes-molecule yes-kspace yes-user-intel
make -j4 intel_cpu

# Machine

Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
Red Hat Enterprise Linux Server release 7.4 (Maipo)

compiler/intel/18.0 mpi/impi/2018-intel-18.0 numlib/mkl/2018
compiler/intel/17.0 mpi/impi/2017-intel-17.0 numlib/mkl/2017

# Commands

module purge
module load compiler/intel/18.0 mpi/impi/2018-intel-18.0 numlib/mkl/2018
mpirun -np 4 ./lmp_intel_cpu_icc18 -in in.phosphate.em -sf intel -pk intel 0 omp 1 mode double lrt yes -log log.icc18.intel-0_omp-1_lrt.lammps
mpirun -np 4 ./lmp_intel_cpu_icc18 -in in.phosphate.em -sf intel -pk intel 0 omp 1 mode double -log log.icc18.intel-0_omp-1.lammps
mpirun -np 4 ./lmp_intel_cpu_icc18 -in in.phosphate.em -log log.icc18.blank.lammps

module purge
module load compiler/intel/17.0 mpi/impi/2017-intel-17.0 numlib/mkl/2017
mpirun -np 4 ./lmp_intel_cpu_icc17 -in in.phosphate.em -sf intel -pk intel 0 omp 1 mode double lrt yes -log log.icc17.intel-0_omp-1_lrt.lammps
mpirun -np 4 ./lmp_intel_cpu_icc17 -in in.phosphate.em -sf intel -pk intel 0 omp 1 mode double -log log.icc17.intel-0_omp-1.lammps
mpirun -np 4 ./lmp_intel_cpu_icc17 -in in.phosphate.em -log log.icc17.blank.lammps

Michael,

it is indeed best to report this as an issue on github and specifically mention @wmbrownIntel to notify the principal author of the USER-INTEL package.
e-mails to the mailing list have a tendency to get lost, if not acted upon immediately.

thanks,
axel.