deepmodeling / dpdata

A Python package for manipulating atomistic data of software in computational science
https://docs.deepmodeling.com/projects/dpdata/
GNU Lesser General Public License v3.0
195 stars 129 forks source link

[BUG] Wrong cell shape when convert structure between `vasp/poscar` and `lammps/lmp` #651

Open ZLI-afk opened 4 months ago

ZLI-afk commented 4 months ago

Bug summary

When configuration converting between POSCAR and lammps/lmp via dpdata, I get a totally different resulted cell structure. Did I make a mistake or it appears to be a bug? please see details below

dpdata Version

0.2.18

Input Files, Running Commands, Error Log, etc.

Original POSCAR.orig:

Ag1
1.0
   2.5133954500000000    0.0000000100000000    1.4511086900000001
   0.8377991700000000    2.3696512300000001    1.4511086900000001
   0.0000000000000000   -0.0000000000000000    2.9022173800000002
Ag
1
direct
   0.0000000000000000   -0.0000000000000000   -0.0000000000000000 Ag

Convert script:

import dpdata

if __name__ == "__main__":
    print(f"dpdata version: {dpdata.__version__}\n")

    print("########## POSCAR to lmp ##########")
    sys_orig = dpdata.System("POSCAR.orig", fmt='vasp/poscar')
    print(sys_orig.data["cells"])
    sys_orig.to_lammps_lmp("conf.lmp")

    print("########## lmp to POSCAR ##########")
    sys_after = dpdata.System("conf.lmp", fmt='lammps/lmp')
    print(sys_after.data["cells"])
    sys_after.to_vasp_poscar("POSCAR.after")

output:

dpdata version: 0.2.18

########## POSCAR to lmp ##########
[[[ 2.51339545e+00  1.00000000e-08  1.45110869e+00]
  [ 8.37799170e-01  2.36965123e+00  1.45110869e+00]
  [ 0.00000000e+00 -0.00000000e+00  2.90221738e+00]]]
########## lmp to POSCAR ##########
[[[ 2.51339545  0.          0.        ]
  [ 0.83779917  2.36965123  0.        ]
  [ 0.         -0.          2.90221738]]]

POSCAR.after:

Type_01 
1.0
2.5133954500000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 
8.3779917000000004e-01 2.3696512300000001e+00 0.0000000000000000e+00 
0.0000000000000000e+00 -0.0000000000000000e+00 2.9022173800000002e+00 
Type_0 
1 
Cartesian
   0.0000000000    0.0000000000    0.0000000000

Steps to Reproduce

  1. prepare POSCAR.orig
  2. run the script
  3. get POSCAR.after

Further Information, Files, and Links

No response

AnguseZhang commented 4 months ago

Did you use the official version of dpdata instead of your modified version? In my enviroment where dpdata is directly installed via pip, the results seem different. Although the direct format is changed to cartesian format ( and the direction also changes), the structure is correct.

dpdata version: 0.2.18

########## POSCAR to lmp ##########
[[[2.90221865e+00 5.62047878e-17 7.56157145e-17]
  [1.45110951e+00 2.51339452e+00 7.56157145e-17]
  [1.45110805e+00 8.37797708e-01 2.36965106e+00]]]
########## lmp to POSCAR ##########
[[[2.90221865 0.         0.        ]
  [1.45110951 2.51339452 0.        ]
  [1.45110805 0.83779771 2.36965106]]]
ZLI-afk commented 4 months ago

Ok. It seems that a complete skipping of post function rot_lower_triangular related to #641 can lead to this issue. But it still do reorient my input structure unexpectedly when the function turns on. Maybe there is a better way to fix this?

njzjz commented 4 months ago

rot_lower_triangular should be moved to the lammps part. The current behavior is not correct.