Rerun only dumping 1st snapshot

LAMMPS LAMMPS General Discussion
,
1

I want LAMMPS to post-simulation calculate some atomic properties via a rerun command. I’ve simplified the script/files [below]. When I run the code in the 22Dec22 LAMMPS, it only dumps the first snapshot to the ‘nbbpots.out’ dump file, despite log.lammps saying it read all 3 snapshots. The exact same code dumps all 3 snapshots in the 29Sept21 version of LAMMPS.

Any ideas what’s wrong? I’ve tried manually setting “first 0 last 5 every 0 skip 1” in the rerun command with no change.

#LammpsScript

dimension 3
units lj
boundary p p p
atom_style full
pair_style coul/long 3.0
kspace_style pppm 1.0e-3

read_data “bNoBond.data”

mass * 1
pair_coeff * *
dielectric 1

group ell type 1

dump 4 ell custom 1 nbbpots.out id
rerun ovito.trj post yes dump x y z

#bNoBond.data
LAMMPS data file via write_data, version 29 Oct 2020, timestep = 20000000

6 atoms

5 atom types

0.0 76.7 xlo xhi
0.0 76.7 ylo yhi
0.0 76.7 zlo zhi

Atoms

2 1 1 0.5 79.2297 -9.80418 83.3879
5 1 3 0 78.7101 -10.6118 83.0376
6 1 3 0 78.5278 -11.5539 83.2242
7 1 4 0 78.3218 -12.4895 82.928
8 1 5 -1 -95.559 204.093 -523.668
10 1 1 0.5 79.8389 -9.49286 82.8393

#ovito.trj
ITEM: TIMESTEP
0
ITEM: NUMBER OF ATOMS
6
ITEM: BOX BOUNDS pp pp pp
0.0000000000000000e+00 7.6700000000000003e+01
0.0000000000000000e+00 7.6700000000000003e+01
0.0000000000000000e+00 7.6700000000000003e+01
ITEM: ATOMS id type xu yu zu c_orient[1] c_orient[2] c_orient[3] c_orient[4] v_shapesx v_shapesy v_shapesz
2 1 79.1845 -9.84139 83.3029 0.813214 0.145282 -0.47331 0.305867 0.75 0.5 0.75
5 3 78.7368 -10.5875 82.9065 0 0 0 0 0 0 0
6 3 78.2811 -11.475 83.2345 0 0 0 0 0 0 0
7 4 78.2911 -12.4708 83.0125 0 0 0 0 0 0 0
8 5 -95.7355 204.058 -523.62 0 0 0 0 0 0 0
10 1 79.8021 -9.47621 82.9337 -0.565752 -0.239437 0.582011 0.532783 0.75 0.5 0.75
ITEM: TIMESTEP
50
ITEM: NUMBER OF ATOMS
6
ITEM: BOX BOUNDS pp pp pp
0.0000000000000000e+00 7.6700000000000003e+01
0.0000000000000000e+00 7.6700000000000003e+01
0.0000000000000000e+00 7.6700000000000003e+01
ITEM: ATOMS id type xu yu zu c_orient[1] c_orient[2] c_orient[3] c_orient[4] v_shapesx v_shapesy v_shapesz
2 1 79.2297 -9.80418 83.3879 0.794178 0.0549076 -0.287607 0.532493 0.75 0.5 0.75
5 3 78.7101 -10.6118 83.0376 0 0 0 0 0 0 0
6 3 78.5278 -11.5539 83.2242 0 0 0 0 0 0 0
7 4 78.3218 -12.4895 82.928 0 0 0 0 0 0 0
8 5 -95.559 204.093 -523.668 0 0 0 0 0 0 0
10 1 79.8389 -9.49286 82.8393 -0.567178 -0.163033 0.582503 0.558945 0.75 0.5 0.75
ITEM: TIMESTEP
100
ITEM: NUMBER OF ATOMS
6
ITEM: BOX BOUNDS pp pp pp
0.0000000000000000e+00 7.6700000000000003e+01
0.0000000000000000e+00 7.6700000000000003e+01
0.0000000000000000e+00 7.6700000000000003e+01
ITEM: ATOMS id type xu yu zu c_orient[1] c_orient[2] c_orient[3] c_orient[4] v_shapesx v_shapesy v_shapesz
2 1 79.2929 -9.80052 83.3505 0.752035 -0.0301009 -0.0930571 0.651826 0.75 0.5 0.75
5 3 78.8451 -10.5954 83.2604 0 0 0 0 0 0 0
6 3 78.6649 -11.5803 83.1604 0 0 0 0 0 0 0
7 4 78.3841 -12.4837 82.8559 0 0 0 0 0 0 0
8 5 -95.4122 204.126 -523.691 0 0 0 0 0 0 0
10 1 79.833 -9.5075 82.7521 -0.663882 -0.0362366 0.50996 0.545791 0.75 0.5 0.75

2

Please try:

3

This perhaps needs a little explanation: about a year ago, in LAMMPS version 7 Jan 2022, the way how dumps select when to write to their files was changed internally to support not only choosing based on a timestep number but also on time. This added a few restrictions (you cannot change the timestep when you have an active dump), broke some functionality and made other behave inconsistently or different from how it was originally intended. The rerun command has been particularly affected since it bypasses a lot of steps happening during a “normal” simulation. Where possible, corrections or adjustments were implemented. For this case there was still some logic missing. If you set the “every” frequency to exactly the same as the trajectory file, then the current code will still work. If every is more frequent (i.e. the number smaller as recommended in the documentation), however, then LAMMPS will no longer consider the dump as eligible for output because of internal function calls that are skipped.

I have added some workaround to the rerun code that should restore this functionality to the documented behavior and also add new support for using a time based output frequency or obtaining the output frequency from a variable. This will be made available in the next LAMMPS patch release (within the next month).

4

Ah, Copy that.
dump 50 worked.
Thanks!