Atoms collapse for larger monolayer system despite running perfectly for smaller system with identical input script and initialization

I am encountering a strange issue when running the same simulation for two systems of different sizes. As shown in the attached image, the monolayer starts bending significantly in the z-direction, forming large out-of-plane waves. The sheet should remain relatively flat in the xy plane, but instead it develops strong curvature and eventually collapses even before applying the deformation.

I am using exactly the same input script, potential, and simulation settings. When I run a 120 × 120 monolayer, the simulation runs without any file errors and the results look reasonable. However, when I run a 150 × 150 monolayer using the same setup, the atoms collapse after the two ensembles (see attached image).

I would like to understand what might be causing this behavior.

To clarify a few points:

  1. Both systems were generated from the same primitive unit cell using Atomsk. The smaller and larger monolayers were created with the same procedure using atomsk, so I believe the structure generation itself is not the issue.

  2. Initially, I did not include energy minimization or neighbor settings and didn’t assign any initial velocities in the input script. The paper from which I adopted the initialization conditions also did not include these steps, and the 120 × 120 system worked fine without them. So I tried running the larger system with and without these modification but the same issue still occurs.

    3. I also tested different boundary conditions such as shrink-wrapped and fixed boundaries, but the issue still persists.

  3. A sufficient vacuum region was provided in the z direction since this is a monolayer system, although I am not sure whether this is relevant to the problem.

Here is the input script

# Uniaxial tensile test for Ti2N

##---------------INITIALIZATION-------------------------------

units metal

dimension 3

boundary p p p

atom_style atomic

newton on

##---------------ATOM DEFINITION------------------------------

read_data Ti2N_main_data_file.lmp

##---------------FORCE FIELDS---------------------------------

pair_style meam

pair_coeff * * library.meam Ti N TiN.meam Ti N

##---------------NEIGHBOR SETTINGS----------------------------

neighbor 2.0 bin

neigh_modify every 1 delay 0 check yes

##---------------ENERGY MINIMIZATION--------------------------

min_style cg

minimize 1e-10 1e-10 1000 10000

##---------------INITIAL VELOCITIES ---------------------

velocity all create 300 12345 dist gaussian rot yes

##---------------SETTINGS-------------------------------------

timestep 0.001

variable ts equal 0.001

##---------------COMPUTES-------------------------------------

compute 1 all stress/atom NULL

compute 2 all reduce sum c_1[1] c_1[2]

variable Lx equal lx

variable Ly equal ly

variable Lz equal lz

variable Vol equal vol

variable thickn equal 2.29

##---------------RELAXATION-----------------------------------

fix 1 all nvt temp 300 300 0.05

thermo 200

run 3000

unfix 1

fix 1 all npt temp 300 300 0.05 x 0 0 0.5 y 0 0 0.5

thermo 2000

run 30000

##---------------DEFORMATION PREPARATION----------------------

unfix 1

reset_timestep 0

fix 1 all nvt temp 300 300 0.05

fix 2 all ave/time 1 100 100 c_2[1] c_2[2]

fix 3 all ave/time 1 100 100 v_Lx v_Ly v_Lz v_Vol

variable srate equal 3.0e9

variable srate1 equal “v_srate / 1.0e12”

fix 4 all deform 1 y erate ${srate1} units box remap x

run 100

##---------------THERMO OUTPUT--------------------------------

variable CorVol equal f_3[4]*v_thickn/(f_3[3])

variable ConvoFac equal 1/1.0e4

variable sigmaxx equal f_2[1]*v_ConvoFac/v_CorVol

variable sigmayy equal f_2[2]*v_ConvoFac/v_CorVol

variable StrainPerTs equal v_srate1*v_ts

variable strain equal v_StrainPerTs*step

thermo 100

thermo_style custom step temp v_strain v_sigmaxx v_sigmayy pe ke lx ly vol

##---------------DUMP FILES-----------------------------------

dump 1 all atom 100 Ti2N_tensile.lammpstrj

dump 2 all custom 100 Ti2N_stress.lammpstrj id type x y z c_1[1] c_1[2] c_1[3] c_1[4] c_1[5] c_1[6]

##---------------STRESS STRAIN OUTPUT-------------------------

fix 5 all print 100 “$(step) {strain} {sigmaxx} ${sigmayy}” file Ti2N_stress_strain.txt screen no title “step strain sigmaxx sigmayy”

##---------------DEFORMATION RUN-------------------------------

run 90000

It is hard to tell without seeing the input files, could you provide them? (potential files as well)

I’m suspecting that you use the same box sizes for both 120 x 120 system and 150 x 150 system, which could cause the ‘‘shrinkage’’.

It was just an assumption, it is clear for you but wasn’t that clear for us without your data files.

In your ‘‘Ti2N_main_data_file_120by120.lmp’’ data file atom 1 is N, atom 2 is Ti.
But in ‘‘Ti2N_main_data_file_150by150.lmp’’ data file atom 1 is Ti, atom 2 is N.

You should define the atom names in correct order when defining pair coeff

Hey Thank you so much for pointing this out. I honestly did not notice this small but critical detail before.

After checking the files more carefully, I found that this was indeed the root cause of the problem. The atom type ordering in the data files was inconsistent:

  • In Ti2N_main_data_file_120by120.lmp:
    atom type 1 = N, atom type 2 = Ti

  • In Ti2N_main_data_file_150by150.lmp:
    atom type 1 = Ti, atom type 2 = N

After correcting the atom types in the 150 × 150 system to match the ordering of the working 120 × 120 system, the collapse issue disappeared.

However, this raised another question that I do not fully understand.

Looking at the library.meam and TiN.meam files, it appears that Ti is listed first and N second. In my input script I also defined the pair coefficients in that order:

pair_coeff * * library.meam Ti N TiN.meam Ti N

Logically, this suggests that Ti should correspond to atom type 1 and N to atom type 2. That is exactly how the 150 × 150 system was originally defined, yet that configuration produced the unphysical collapse.

On the other hand, the configuration where N is type 1 and Ti is type 2 (which seems inconsistent with the order in the potential files) runs properly and produces reasonable results.

To confirm this, I also modified the 120 × 120 system to use the same atom type ordering as the original 150 × 150 system, and it produced the same instability.

So it seems clear that the atom type ordering is the root cause, but I do not fully understand why the seemingly “incorrect” ordering works while the logically consistent one does not.

Do you have any idea regarding this bias? Maybe I should also create a separate topic of discussion on this.

The explanation of the ordering is given in the MEAM pair style documentation.

For the order after library.meam the ordering in the TiN.meam file matters, since in this file the atom types are referred to by numbers (1, 2, 3, etc) and you have to “extract” the parameters from the library.meam file in the same order or you will get incorrect results.

For the order after TiN.meam the order in the data file or however you create the atoms matters.
So you can have Ti N in one case and N Ti in the other.

Thanks, I did check out the documentation, and the correct order should be Ti as 1 and N as 2 which is causing the error unfortunately, could you please check the topic which I made separately regarding this issue ( MEAM potential for Ti–N: “Correct” atom type mapping causes collapse while swapped mapping works and matches literature )
Thank You.

Sorry, but I am not in the habit of debugging other people’s research projects.

There are two issues that I would like to point out:

  1. the free energy of a folded system is generally lower than for a flat system. As soon as you simulate the system with fix npt there is a chance it will bend or “crumple up” and there is no driver to keep it flat. this is not unlike a table cloth which requires to be pulled on the side to remain flat. … and a table cloth has the table as support, for which there is no equivalent in your setup.
  2. the larger your system gets, the easier it will become for the system to bend in z-direction. a) because less force is required and b) because larger systems allow for lower frequency motions. Keep in mind that you add kinetic energy to the system, so it will have motion.

You will have to study the simulation protocol(s) employed by similar studies to make certain that you are doing what is reasonable. Please always keep in mind that at the atomic scale you cannot easily apply and expect the same behavior as for macroscopic systems.

2 Likes

Thank you for the explanation and for pointing this out.That makes sense. I will look into it, I appreciate the clarification.