Ewald summation in a 2D system

I’m trying to simulate a 2D system where I want to evaluate long-range dipolar interactions using Ewald summation with the slab geometry method. In this approach, a vacuum slab is introduced between periodic images along the z-direction, and a correction term is added to the energy to cancel out interactions in that direction.

To constrain the motion to the 2D x-y plane, I’m also using the enforce2d command, which explicitly sets the z-components of velocity and force to zero for each particle. This keeps the particles confined to the plane.

However, I’m unsure whether using these two methods together is valid. The LAMMPS documentation doesn’t explicitly state whether combining kspace_modify slab and enforce2d is allowed or recommended.

Kindly help

This is my script

dimension 3
boundary p p f
atom_style hybrid sphere dipole
units lj
region Sregion block 0 30 0 30 -0.7 0.7 units box
create_box 1 Sregion

create_atoms 1 random 102 321 Sregion
set atom * z 0
mass 1 1
fix 1 all enforce2d
variable dt equal 0.001
pair_style lj/cut/dipole/long 2.5 5
pair_coeff * * 1 1
set type 1 charge 0

set group all dipole/random 654 1.732

kspace_style ewald/dipole 1.0e-3
kspace_modify slab 3
neighbor 2.0 bin
neigh_modify delay 1 every 1 check yes
minimize 1.0e-6 1.0e-8 1000 1000
fix 2 all nve/sphere update dipole
timestep ${dt}

velocity all create 2.0 987 dist gaussian mom yes rot yes
fix nvt all nvt temp 2 2 $(100.0*dt)
thermo_style custom step time temp pe ke etotal press
dump dump_1 all custom 1000 melting3.dump id type x y z mux muy muz
run 300000
unfix nvt
undump dump_1

So you need to construct some representative (and sufficiently simple) test geometries and verify the resulting behavior. It is also straightforward to look at then source code of fix enforce2d to see if this is going against your expectations and make checks for the slab correction if it gives consistent results.

It is in general considered a best practice in simulations to make tests for any feature that you have not yet used to make certain your understanding matches the implementation and that it produces physically meaningful results for your application. It is impossible to do this from the onset during development, since there are too many permutations of settings and features is a large software package. In addition, while certain combinations of features may be invalid for some setups and simulations, they may be a good choice in others. Where it is know beyond a doubt and meaningful checks are possible, LAMMPS code will error out. But that applies only to a subset. If LAMMPS would only allow settings it can be checked as certain to be correct, many simulations would be stopped.

Thanks.

Arpit