Nanocutting (atoms flying out)

Hi, I am trying to run simulation of nanocutting of amorphous material CuZr by using diamond tool. The steps i have taken is to first prepare CuZr in a separate file, then generate datafile to be read into cutting input file.

Lammps version: LAMMPS 64-bit 27May2021
Procedure of preparing CuZr: minimization, melting, freezing, replication, relaxation.
Potentials I am using is MEAM for Cu-Zr, and Morse for Cu-C/Zr-C.

when I run my cutting input file, the workpiece(CuZr) atoms scatter right away in all directions.
I realised that there are some atoms overlapping between the boundaries.
There are three region: boundary, temp-layer and newton layer.
Workpiece has 100000 atoms, but the total number of atoms of the three regions is 100060.
I wonder if this extra 60 overlapped atoms caused this problem.

after minimization, workpiece looks weird as well.

after 10000 steps, lost atom (2.0 KB)

I have attached the cutting input file. The CuZr file is too big, so if it is needed, I could share a link later.
It would be great if anyone could provide some guidance. Thank you very much.

This looks as if the procedure to generate the data file for the workpiece is already resulting in bogus data. Most likely some error in the MEAM potential parameters.

There is a CuZr eam/fs potential bundled with LAMMPS, I would try with that first to see if that makes a difference. If yes, then you know what you need to debug/correct.

I would also suggest to create a much smaller input deck with much fewer atoms for testing/debugging.
Otherwise you are just wasting time (yours and your computer’s). The basic simulation protocol can be tested and checked with a much smaller system just as well.

Noted. I will try to first look at eam potential files and use smaller system for testing.
Thank you very much @akohlmey.

Hi @akohlmey
I tried with eam/fs taken from Interatomic Potentials Repository and smaller system, but the results were similar.
So far the eam/fs files I have tried were Cu-Zr_4.eam.fs and Cu-Zr_3.eam.fs
Atoms are still flying out.

Cu-Zr_4.eam.fs (2.2 MB)

cube.dat (259.4 KB) (2.2 KB)

I see two problems with your input deck. Your data file (cube.dat) as non-zero image flags for non-periodic directions. That should not be. Also that configuration needs to be relaxed and equilibrated and that is best done beforehand in its original box.

A second problem seems to be in bad choices for which atoms to immobilize and then changes in the last step where you suddenly release atoms that were previously immobilized and are no released and because of having high potential energy, they will fly away. Already in the first step too few atoms seem to be immobilized, but those are “released” in the last step which causes the crash. You can easily see this from the attached images. I’ve colored the (originally) immobilized atoms in blue. It works well until the end of the step3 trajectory file.

Step 1:

Step 2:

Step 3:

Step 4:

@akohlmey thank you for your advice.

As for problem 1, I am trying to solve “non-zero image flags for non-periodic directions” right now, as my cube data file was written with periodic boundaries and then read back for non-periodic boundaries in testcut1 file. I have gone through related info via read_data and also some of your comments, you mentioned that “it is best to use the change_box command to enlarge the box but do it with an empty group of atoms”. I am sorry but I could not understand this.
It would be great if you could go through once the steps for using change_box method to solve this problem.
As for problem 2, according to testcut1 input file, I didnt release boundary atoms after step3 but the results show that. I wonder if problem 1 is related to problem 2, and if problem 1 is solved, problem 2 might be resolved as well?

Thank you very much.

You can reset image flags with the set command. Since you have not a molecular system, it is a safe operation. You can also have a minimal input file with just read_data and write_data, the new boundaries and whatever else is needed for this. The read_data should reset all non-zero image flags on reading and print a message about it.

As for change_box. The command operates on a group. If you change the box dimensions, atoms in the group will be rescaled to the new box, other atoms will remain in place. If you define an empty group, there will be no rescaling.

Details about all of this are in the manual. Please have a careful read of the docs for the commands mentioned and related commands.

Hi @akohlmey , thank you very much for your explanation.

I have resolved the problem of “non-zero image flags for non-periodic directions”.
Right now I am trying to solve problem of my workpiece.
There are three layers for my workpiece: boundary layer (fixed), temp_layer (thermostat) and newton_layer. The boundary layer is used to support the whole system, while the temp_layer is used to maintain them at a constant temperature of 293K.

I managed to fix the boundary layer, but the temp_layer is giving me alot of trouble.
End of 1st step (after minimization)
end of step1
I have no idea what is going on here.
I had undergo minimization, melting, freezing, relaxation for my original cube before i replicate it into my workpiece.

End of 2nd step (temp_layer relaxation)
end of step2

It seems that type 1 atom Cu fly away( I guess its due to high potential energy again).
It would be great if you could provide some insights on how to solve this kind of problem.
I have attached files of a smaller system without the tool. Thank you in advance.

Sorry, but this is not really a discussion about LAMMPS itself anymore but about how to set up and implement your models and simulations. That is something you need to discuss with your advisers and people familiar with your kind of research. Complex simulations need to be build in stages and where you verify at each step that things are working as expected. That - again - is more a question about how to do research than about LAMMPS.


These images look very nice. Where they made with some free software? If so, would you let me know which one is it.


I do my LAMMPS visualizations with VMD.

Noted. Thank you very much @akohlmey .

Oh okay. Thanks. Didn’t know that VMD can output such high quality visualizations.

Hi @akohlmey, it turns out that the problem was with the read_data command.

I tried to write data of the whole model (tool+workpiece) and I realised that element type 2 duplicated and became type 1 as well.

Copied from model data file


1 63.546
2 63.546
3 91.224

Where it should be:
type 1: C (28.085)
type 2: Cu (63.546)
type 3: Zr (91.224)

From my input file, I first created type 1 atom for the tool, then only I read the workpiece data.
I used read_data append where “atoms in the data file are added to the current system, with their atom IDs reset so that an atom-ID = M in the data file becomes atom-ID = N+M, where N is the largest atom ID in the current system.” However, I dont know why it is not working for my case.

Part of input file

region simbox block 0 290 0 180 0 36
create_box 3 simbox

region tool block 240 290 130 180 0 36

lattice diamond 3.6
create_atoms 1 region tool
mass 1 28.085

region boundary1 block 0 20 0 150 0 36 units box
region boundary2 block 20 240 0 20 0 36 units box
region boundary union 2 boundary1 boundary2
region temp_layer1 block 20 40 20 150 0 36 units box
region temp_layer2 block 40 240 20 40 0 36 units box
region temp_layer union 2 temp_layer1 temp_layer2
region newton_layer block 40 240 40 150 0 36 units box
region piece union 3 boundary temp_layer newton_layer

read_data workpiece.dat add append

pair_style hybrid eam/fs morse 2.5
pair_coeff 1 1 morse 3.1 4.9519 1.2419 #C-C
pair_coeff 1 2 morse 0.087 5.14 2.05 #C-Cu
pair_coeff 1 3 morse 1.56 3.3786 2.1187 #C-Zr
pair_coeff * * eam/fs Cu-Zr_4.eam.fs NULL Cu Zr

group boundary region boundary
group temp_layer region temp_layer
group newton_layer region newton_layer
group tool region tool
group mobile union temp_layer newton_layer


I wonder what is the reason causing this problem. Thank you in advance.
I am currently using LAMMPS 64-bit 30Jul2021.

Please read more carefully! This refers to atom IDs and NOT atom types. The atom types (and bond/angle/dihedral/improper types) for atoms in the data file remain unchanged unless the offset keyword is used.

@akohlmey I am so sorry for not doing my research carefully. Thank you very much!