Why does the Lammps simulation not reach the end for a lower dumping frequency?

Dear LAMMPS community members,

I am running NVT-MD simulations using LAMMPS (version 22Jul2025). I use periodic boundary conditions (PBC) for a small box measuring 12.76 Å x 12.76 Å x 10.21 Å.
I am dealing with CH structures containing between 80 and 120 atoms, depending on the H/C ratio.

I am performing a series of quick ramps (under 1 ps) to a higher temperature (T1) after 5 ps of equilibration at room temperature. After a further 10 ps of equilibration at T1, I decrease to a lower temperature (T2), which is still relatively high but lower than T1 and much higher than room temperature. The temperature change always takes 1 ps, and finally I cool the structures down to room temperature. This process enables me to create amorphous hydrocarbons (a-C:H).

I am interested in evaluating the mean-squared displacement (MSD) alongside other quantities. To do this, I follow these steps:

# variable declaration Dt, dur<x> dumping frequency etc

variable frame_dump_freq    equal 100                       
variable print_freq         equal "v_frame_dump_freq / 10"
...

units metal
dimension 3
boundary p p p
atom_style atomic
read_data init.lmp
labelmap atom 1 C 2 H
group Carbon type 1
group Hydrogen type 2

pair_style ...
pair_coeff ...

...

dump          1 all custom ${frame_dump_freq} trajectory.lammpstrj id element x y z vx vy vz fx fy fz 
dump_modify   1 flush yes sort id element C H

...

compute     myMSD all msd

...

fix         MSD_output all ave/time 1 1 ${print_freq} c_myMSD[1] c_myMSD[2] c_myMSD[3] c_myMSD[4] file msd.txt title1       "# Step  MSD_x  MSD_y  MSD_z  MSD_total"

...

# equilibration @ Troom 

timestep    ${Dt}
fix         1 all nvt temp ${T0} ${T0} $(100.0*dt)
run         ${dur1}

# quick ramp to T1

fix         1 all nvt temp ${T0} ${T1} $(100.0*dt)
run         ${dur2}

# equilibration @ T1

fix         1 all nvt temp ${T1} ${T1} $(100.0*dt)
run         ${dur3}

# quick ramp to T2

fix         1 all nvt temp ${T1} ${T2} $(100.0*dt)
run         ${dur2}

# equilibration @ T2

fix         1 all nvt temp ${T2} ${T2} $(100.0*dt)
run         ${dur3}

# cool down to T0

fix         1 all nvt temp ${T2} ${T0} $(100.0*dt)
run         ${dur2}

# equilibration @ T0

fix         1 all nvt temp ${T0} ${T0} $(100.0*dt)
run         ${dur3}

...

So I conducted two simulations using frame_dump_freq = 1000 & 100. Surprisingly, the lower frequency rate (i.e less frame saving) of each 1000 steps crush however with 100 continue until the end !

I lunched two calculations and the comparison :

>> diff frame_dump_freq_1000/init.lmp frame_dump_freq_100/init.lmp # identical files (sanity check)
>> diff frame_dump_freq_1000/input.lmp frame_dump_freq_100/input.lmp  # what changed is frame_dump_freq    
29c29
< variable frame_dump_freq    equal 1000
---
> variable frame_dump_freq    equal 100

>> tail frame_dump_freq_1000/log.lammps frame_dump_freq_100/log.lammps 

==> frame_dump_freq_1000/log.lammps <==
    163200   33851.996      485.70425     -25943.175     -25457.471      2158657.9      1139.6991      1.4469968
ERROR: Number of atoms in compute msd group must not change. (src/lammps-22Jul2025/src/compute_msd.cpp:148)

==> dump_freq_100/log.lammps <==

# save structure:

write_data amourphous_CH.lmp
System init for write_data ...

Total wall time: 0:25:14

Both simulations have the following SLURM configurations:

>> frame_dump_freq_100/job.sh
#SBATCH -n 20                      # on 20 cores nodes
#SBATCH --cpus-per-task=1

>> frame_dump_freq_1000/job.sh
#SBATCH -n 8                        # on 16 cores nodes
#SBATCH --cpus-per-task=1

I don’t find this logical at all, or it is ?

Thank you in advance, for your suggestions and answers.

Anouar

There is not enough information here to make any specific assessment. The fact that the number of atoms changes indicates that you are losing atoms which is a sign of bad dynamics. You need to investigate that first. Possibly your simulation settings are too aggressive and you results are all destined for the trashcan.