I tried to simulate the process of moving the entire Si3N4 hemisphere by moving the upper group of the hemispere , but the lower part didn’t follow the upper group to move.
Below is my input file and pictures. Hopefully some one can shed light on this problem.
units real
dimension 3
boundary p p f
neighbor 2 bin
atom_style full
neigh_modify delay 5
pair_style tersoff
read_data si3n4.data
pair_coeff * * SiNCkrollorigin.tersoff N Si
#region
region si3n4up block -15 15 -15 15 -6 2
group si3n4up region si3n4up
compute tep all temp
velocity all create 300 987098 temp tep
fix 1 all nvt temp 300 300 100
fix 2 si3n4up setforce 0 0 0
fix 3 si3n4up move linear 0.1 0 0
timestep 0.1
thermo 100
dump 1 all custom 100 nvtxyz.lammpstrj id type x y z
run 1000
Please check your output for warnings. There should be one about time integrating atoms multiple times. That is your problem. Also, you are STILL assigning velocities to atoms you apply fix setforce 0 0 0 to. This is the last time I I am pointing this out to you. Ignore it one more time, and you need to find someone else to get help from, since choose to not help people that don’t pay attention.
Axel
Greetings,
Lot of reasons really. While I can’t point out why without more info I can provide the following advice to simplify the input and sources of error:
-
you shouldn’t use fix nvt on group all (use a group subtracting your movement region from all) since it conflicts with fix move.
-
fix move already assumes constant velocity on the specified group so there’s nothing gained by using set force on the region if no other fixes apply to
the group with the first change made.
-
Probably check your potential parameters and your timestep’s validity for the Tersoff potential.
Adrian
Now that I look at it you’re simulating something with Silicon and the tersoff potential using a 0.1 ps timestep when I’m accustomed to seeing 0.001 or even 0.0005 for things involving silicon. I may be off base given your system might be completely different from the solids I’m used to simulating but making it smaller might help the two parts of your simulation model to interact correctly assuming the potential parameters are all correct.
Adrian
units are real, and the timestep of 0.1fs rather on the small side. 1fs or more should be possible with the elements at hand. the problem is the overlapping time integration and - as with cases posted here before - the ignorance of warnings that LAMMPS prints in the output. GI-GO.
axel.
Oh yea I missed that; in that case the velocity given to fix move seems to me quite high at 100 A/ps even if the overlapping fixes were corrected.
Adrian