Mobile layer moving faster than Boundary layer

Hello all…

I am simulating the cutting phenomenon in which tool is scratched over the work piece. Both are having boundary, thermostat and newtonian layer.

1 However with velocity given to tool, mobile atoms of the tool are moving much faster than boundary atoms of the tool. What could be the problem???

Figures are attached.

2) I have used fix temp/rescale for equillibration as well as in thermostat layer after equillibration. But some suggest its use is obsolete and rather fix langevin temp should be used.

Please suggest…

Part of the script file.

initial velocities and equilibrate

velocity mobile create 300 482456 temp new
fix 1 TW_bound setforce 0.0 0.0 0.0 ## boundary atoms of tool-workpiece
fix 2 all nve
fix 3 all temp/rescale 5 300.0 300.0 0.05 1.00 ####thermal scaling/equilibration

fix 3 w_thermo langevin 300.0 300.0 2.0 699483

fix_modify 3 temp new

thermo 100
thermo_modify temp new
dump 1 all custom 100 alleq1.*.dump id type x y z vx vy vz fx fy fz

run 1000

Tool displacement

timestep 0.001 ##10 fs
velocity tool set -2.0 0.0 0.0 sum yes units box
unfix 3
fix 3 TW_thermo temp/rescale 10 300.0 300.0 0.01 1.0 ## thermostat layer
#fix 3 w_thermo langevin 300.0 300.0 10.0 699483 ##thermostat layer.
thermo 100
dump 2 all custom 50 alldy.*.dump id type x y z vx vy vz fx fy fz
run 120000

Thanks in advance

1.jpg

3.jpg

This is not a LAMMPS question. Neither LAMMPS nor nature has a law stating that “mobile atoms of the tool shall not move much faster than boundary atoms of the tool.” In any case, your picture 3.jpg is consistent with my expectations. The atoms of the workpiece are forming a free surface jet ahead of the tool, much like what you would see if the undeformed workpiece was a liquid. If you find this surprising, consider that your tool is infinitely strong and moving at 200 m/s, about 100 times faster than the fastest high speed lathes.

Thanks for the reply…

well this is the speed(10-200m/s) researchers are using as mentioned in literature.
however if i use fix langevin command, this problem doesn’t appear(as shown in fig.), but thermostat atoms of workpiece are losing their position.

So, what could be the possible reason a how to resolve it??

1.jpg2.jpg

Thanks for the reply..

well this is the speed(*10-200m/s*) researchers are using as mentioned in
literature.
however if i use* fix langevin command*, this problem doesn't appear(as
shown in fig.), but *thermostat atoms of workpiece* are losing their
position.

So, what could be the possible reason a how to resolve it??

​it should be pretty obvious from simply looking at your images, that your
"blue" atoms do not interact with your "red"​ atoms and thus can move
around freely. that is obviously a mistake in your input, possibly an
incorrect neighbor list exclusion or a missing pair_coeff statement.

axel.

1.jpg

2.jpg

Hi,

Outer red layer of the workpiece is boundary layer which has been made rigid by fix setforce 0.0 command. in between is a thermostat layer.
I think if it is rigid it will not interact with mobile layer.

all other things are same as written in first mail except that fix langevin command has been used for the production run in the 2nd simulation as mentioned in 2nd mail.

initial velocities and equilibrate

velocity mobile create 300 482456 temp new

fix 1 TW_bound setforce 0.0 0.0 0.0 ## boundary atoms of tool-workpiece

fix 2 all nve
fix 3 all temp/rescale 5 300.0 300.0 0.05 1.00 ####thermal scaling/equilibration

fix 3 w_thermo langevin 300.0 300.0 2.0 699483

fix_modify 3 temp new

thermo 100
thermo_modify temp new
dump 1 all custom 100 alleq1.*.dump id type x y z vx vy vz fx fy fz

run 1000

timestep 0.001 ##10 fs

velocity tool set -2.0 0.0 0.0 sum no units box #### tool velocity sum yes### velocity_tool-mobile is increasing
#unfix 2
unfix 3

Tool displacement

#fix 3 TW_thermo temp/rescale 10 300.0 300.0 0.01 1.0 ## thermostat layer
fix 3 w_thermo langevin 300.0 300.0 100.0 699483 ##thermostat layer

2.jpg

1.jpg

I missed the layer of light blue atoms in your first images. Clearly, you are doing something to the velocities of those atoms to cause them to change from -2 A/ps, probably through the rescale thermostat. It’s impossible to tell by just looking at a partial script. In the second images, as Axel suggested, the blue/purple atoms do not seem to be interacting with the red. Again, without seeing the full script, it is impossible to tell. From the parts of the script that I can see, I have the sense that you are jumbled things up unnecessarily. I suggest you try cleaing things up before proceeding. In particular, avoid applying fixes to the group ‘all,’ as that can create a variety of unexpected behaviors.

1.jpg

2.jpg

hi,

I also ran simulation by applying fix to mobile layer only (fix 2 mobile nve) instead of applying fix to all. In that case tool atoms are held together but the tool is not moving in -ve X-direction, so cutting could not occur.

script file is attached. Kindly Suggest if something can be improved.

2.jpg

1.jpg

script.txt (4.83 KB)

The main problem with your script is that you are not being careful enough in applying fixes, particularly the thermostat fixes. You should rewrite your script, adhering to the following principles:

  1. Do not apply a fix to a group of atoms that does not need it (so fix nve should not be applied to your frozen atoms)
  2. Do not apply a thermostat to two or more groups of atoms that have different center-of-mass velocities
  3. For a group of atoms that have a non-zero center-of-mass velocity, use a thermostat that does not modify the center-of-mass velocity

This fix is the main problem:

fix 3 TW_thermo temp/rescale 10 300.0 300.0 0.01 1.0 ## thermostat layer

You are asking LAMMPS to enforce an average temperature of 300 K (thermal velocity ~200m/s), when roughly half of the atoms in group TW_thermo have been assigned a center-of-mass velocity of -200 m/s, while the other half have zero center-of-mass velocity. Don’t do that.

Also, from what you showed us with fix langevin, there seems to be a problem with the 1-2 interaction, or else you were somehow driving the type 2 atoms very hard, hard enough to overcome the EAM repulsion, or maybe something else is going on to allow the type 2 atoms to penetrate the thin layer of type 1 atoms.

There are lots of other minor problems in the script, and there are probably some other major problems that I did not notice. So, instead of tweaking your script one more time, rerunning your simulation, and then posting another open-ended question about how your simulation is not working, please take a few weeks to rewrite your script in a more systematic way, testing each element separately. If you just take a random walk in the high-demensional space of syntactically correct LAMMPS commands, guided only by the desire that LAMMPS do what you want, the chances of you arriving at a valid simulation anytime this year is very small.

Aidan

2.jpg

1.jpg

Thank you Mr. Aidan.

I should have read the Lammps manual very carefully before asking the question.