Cutoff issue from different LAMMPS versions

[acgc99]

I've installed latest LAMMPS version, "29 Aug 2024 - Update 2". These are the instructions I followed:

git clone -b stable https://github.com/lammps/lammps.git mylammps
cd mylammps/src
git clone https://github.com/LLNL/USER-EPH.git
vim Makefile # Add user-eph at the end of `PACKAGE` variable
make yes-manybody yes-extra-fix yes-extra-dump yes-extra-compute yes-extra-command yes-python yes-openmp yes-user-eph
make mpi mode=shlib -j8
make install-python
export LD_LIBRARY_PATH=$HOME/mylammps/src:$LD_LIBRARY_PATH

This is my input script in LAMMPS:

units metal
atom_style atomic
boundary p p p
atom_modify map yes
lattice fcc 3.5365
region full_box block -15 15 -15 15 -15 15
region inner_material block -13 13 -13 13 -13 13
create_box 1 full_box
create_atoms 1 region full_box
group full_box region full_box
group inner_box region inner_material
group thermoboundary subtract full_box inner_box
fix integrate all nve
fix reset all dt/reset 10 1e-05 0.001 0.028664999 units box
pair_style eam/fs
pair_coeff * * eam.Ni.Ni.in_lammps Ni
compute ke all ke/atom
compute pe all pe/atom
compute cna all cna/atom 3.0187
compute coord all coord/atom cutoff 3.0187
velocity all create 600.0 1 loop geom mom yes rot yes
thermo 100
thermo_style custom step dt time temp etotal ke pe
dump dump all custom 1000 simulation.xyz id element x y z c_pe c_ke c_cna c_coord
dump_modify dump element 28
run 1000
unfix integrate
fix eph all eph 1 7 4 1.0 3.5e-6 0.1248 300.0 3 3 3 NULL 1000 egrid/egrid Ni_PRB2019_High_Rho.beta Ni
run 1000

I get this error on the second run:

run 1000
ERROR: Custom neighbor list cutoff too large for communication cutoff (../neighbor.cpp:864)
Last command: run 1000

The script works on "28 Mar 2023 - Development" (some colleague is using it) but I don't feel comfortable using an old development version.

[artuuuro]

Hi,
This issue is related to the cutoff issue being used by the potential file and by the EPH. If you look into the potential file it probably has the cutoff at 4.8 Ang, while the EPH input file Ni_PRB2019.beta has the cutoff at 5.0 Ang.

To solve this this either increase the cutoff in your lammps input file comm_modify cutoff 5.0 or use:

pair_style hybrid/overlay zero 5.0 nocoeff eam/fs
pair_coeff * * zero
pair_coeff * * eam.Ni.Ni.in_lammps Ni

Also, you might want to check the fix eph model selection. In your example you are using model 1, but hte input file was created with model 4. Using wrong model will result in 1) incorrect electron-ion coupling strength and 2) more classical Langevin forces with just density dependent coupling strength.

I will investigate this issue in the future to see if I can force a new cutoff distance from the fix.

[acgc99]

Thanks for your response, it works fine. Some comments:

• comm_modify cutoff 5.0 is not enough, comm_modify cutoff 7.0 is fine. LAMMS adds a 2 angstrom skin in metal units by default.
• Extending the range of the potential changes the dynamics (not ideal).

Also, you might want to check the fix eph model selection. In your example you are using model 1, but hte input file was created with model 4

I'm using fix eph all eph 1 7 4, according to documentation, the 1 is the seed, not the model, right?

I will investigate this issue in the future to see if I can force a new cutoff distance from the fix.

Do you know why these different cutoffs are a problem for LAMMPS 2024 and not for 2023? It might help.

[artuuuro]

Yes, you are correct. The first value is the seed. I got confused with the number 1 being used as seed. In my scripts I have started passing the RNG seed as an argument to avoid issues due to identical starting conditions.
'''
fix friction all eph ${seed_in} ...
'''
and you call lamps with lmp_serial -var seed_in ${RANDOM} (this works with bash, but you can provide a value instead).

[artuuuro]

* Extending the range of the potential changes the dynamics (not ideal).

I did not mean extending the potential by force, but rather adding a zero pair_style (no extra forces) which forces a longer cutoff. This should not affect the EAM potential with a shorter cutoff.

Do you know why these different cutoffs are a problem for LAMMPS 2024 and not for 2023? It might help.
Maybe, because they started checking cutoffs in newer LAMMPS version. They have been messing around with the code a lot in a couple last years. Mostly restructuring it to be more modern C++. But, there could be a bug in my code as well which did not appear before. This is something rather new that I have seen as well, but as I do not have much time for development I did not investigate it further.