[BUG] Incorrect output for triclinic/general when using dump style custom

[nnn911]

Summary

Setting dump_modify triclinic/general yes for a custom dump style modifies the dump file header but not the particle positions. LEading to incorrect output. This can be seen when comparing dump and data files for the same system. My preliminary tests suggest, that the data file contains the correct output.

LAMMPS Version and Platform

• LAMMPS development branch (commit 628531d) (LAMMPS (17 Apr 2024))
• Windows 11 (22631.3527)
• cl.exe --version Microsoft (R) C/C++ Optimizing Compiler Version 19.39.33522 for x64

Expected Behavior

• The simulation cell vectors and atomic positions in data and dump files written with the triclinic/general yes setting should match (up to some precision threshold).
• Dump files written with and without the triclinic/general yes setting should match after appropriate rotation.

Actual Behavior

For this test I compare 3 different files: 1.data (data file written with the default lammps triclinic settings), 1.general.data (data files written with triclinic/general yes, and 1.general.dump (dump files written with the triclinic/general yes setting).

The three different files (abbreviated for clarity):

1.data

...
0 1.0873618812400903 xlo xhi
0 1.883366024521512 ylo yhi
0 2.6634817747910216 zlo zhi
1.0873618812400905 1.631042821860135 0.9416830122607556 xy xz yz
...
Atoms # atomic
1 1 0 0 0 0 0 0
2 1 0.5436809406200452 0.941683012260756 0 0 0 0
3 1 1.6310428218601347 0.313894337420252 0.8878272582636738 -1 0 0
4 1 1.0873618812400903 1.2555773496810079 0.8878272582636738 0 0 0
5 1 2.1747237624801796 0.627788674840504 1.7756545165273476 -1 0 0
6 1 2.7184047031002248 1.5694716871012597 1.7756545165273476 -1 0 0

1.general.data

...
0.768880959828629 0.7688809598286294 0 avec
-2.220446049250313e-16 1.5377619196572587 1.5377619196572585 bvec
2.3066428794858873 -2.220446049250313e-16 2.3066428794858878 cvec
0 0 0 abc origin
...
Atoms # atomic
1 1 0 0 0 0 0 0
2 1 -1.1102230246251565e-16 0.7688809598286294 0.7688809598286293 0 0 0
3 1 1.5377619196572578 0.7688809598286291 0.7688809598286293 -1 0 0
4 1 0.768880959828629 0.7688809598286294 1.5377619196572583 0 0 0
5 1 2.306642879485887 0.768880959828629 1.5377619196572585 -1 0 0
6 1 2.306642879485887 1.5377619196572583 2.3066428794858878 -1 0 0

1.general.dump

...
ITEM: BOX BOUNDS abc origin pp pp pp
7.6888095982862903e-01 7.6888095982862936e-01 0.0000000000000000e+00 0.0000000000000000e+00
-2.2204460492503131e-16 1.5377619196572587e+00 1.5377619196572585e+00 0.0000000000000000e+00
2.3066428794858873e+00 -2.2204460492503131e-16 2.3066428794858878e+00 0.0000000000000000e+00
ITEM: ATOMS id type x y z
1 1 0 0 0
2 1 0.543681 0.941683 0
3 1 1.63104 0.313894 0.887827
4 1 1.08736 1.25558 0.887827
5 1 2.17472 0.627789 1.77565
6 1 2.7184 1.56947 1.77565

Comparing these 3 files reveals that the 1.general.dump file uses the header / cell vectors based on the triclinic/general setting (i.e. the ones found in the 1.general.data file). The atomic positions, however, do not match 1.general.data. Instead, the atomic positions match the 1.data file, meaning that they are still based on non-updated coordinates.

Steps to Reproduce

The three files can be generated using this lammps input script:

lattice       custom 1.1 a2 0.0 0.5 0.5 a3 0.5 0.0 0.5 a1 0.5 0.5 0.0 basis 0.0 0.0 0.0 triclinic/general

create_box    1 NULL 0 1 0 1 0 1
create_atoms  1 box
mass          * 1.0

replicate     1 2 3

write_data    1.general.data triclinic/general
write_data    1.data 


pair_style    lj/cut 1.2
pair_coeff    * * 1.0 1.0

neighbor      0.0 bin

dump          1 all custom 100 1.general.dump id type x y z
dump_modify   1 triclinic/general yes

run           0

Further Information, Files, and Links

I did preliminary testing and I think this issue is caused by the order in which the custom dump style is initialized. First DumpCustom::parse_fields is called in the constructor of DumpCustom. Within in this method the writer for the atomic positions is selected (dump_custom.cpp:1331):

      if (triclinic_general) pack_choice[iarg] = &DumpCustom::pack_x_triclinic_general;
      else pack_choice[iarg] = &DumpCustom::pack_x;

However at this time, the dump_modify command has no been processed yet. Therefore, the triclinic_general flag is 0. At a later time, but before the dump is actually written the DumpCustom::modify_param method is called. This method sets the triclinic_general flag to 1. However, the DumpCustom::parse_fields method is not called again and therefore the pack_choice is never updated to use the triclinic_general methods. Therefore, the output becomes inconsistent.