Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support of all lammps dump coordinate style #179

Merged
merged 9 commits into from
Aug 4, 2021

Conversation

xfanak
Copy link
Contributor

@xfanak xfanak commented Jul 26, 2021

Corresponding tests have been added now.

@amcadmus amcadmus changed the base branch from master to devel July 27, 2021 01:37
@codecov-commenter
Copy link

codecov-commenter commented Jul 27, 2021

Codecov Report

Merging #179 (bde97b1) into devel (ea32d45) will increase coverage by 1.17%.
The diff coverage is 87.50%.

Impacted file tree graph

@@            Coverage Diff             @@
##            devel     #179      +/-   ##
==========================================
+ Coverage   80.07%   81.25%   +1.17%     
==========================================
  Files          54       54              
  Lines        4553     4550       -3     
==========================================
+ Hits         3646     3697      +51     
+ Misses        907      853      -54     
Impacted Files Coverage Δ
dpdata/lammps/dump.py 89.88% <87.50%> (-0.33%) ⬇️
dpdata/rdkit/utils.py 61.79% <0.00%> (-1.00%) ⬇️
dpdata/system.py 82.08% <0.00%> (+0.44%) ⬆️
dpdata/format.py 89.65% <0.00%> (+3.44%) ⬆️
dpdata/md/water.py 64.00% <0.00%> (+20.00%) ⬆️
dpdata/plugins/ase.py 46.15% <0.00%> (+26.92%) ⬆️
dpdata/plugins/pymatgen.py 87.09% <0.00%> (+61.29%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ea32d45...bde97b1. Read the comment docs.

@amcadmus
Copy link
Member

  1. You do NOT need to close open a new PR every time you push commits.
  2. please add the UTs for the cases of "scaled" and "scaled & unfolded"

@xfanak
Copy link
Contributor Author

xfanak commented Jul 28, 2021

UTs for "scaled" and "scaled & unfolded" have been added.

if sf:
posis = (posis%1.)@cell # convert xsu to xs first
else:
posis = (posis - orig)%np.linalg.norm(cell,axis=1)
Copy link
Member

@amcadmus amcadmus Jul 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

%np.linalg.norm(cell,axis=1) would not work for triclinic cells.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. It is %cell.sum(axis=0) now.

@@ -83,7 +83,7 @@ def safe_get_posi(lines,cell,orig=np.zeros(3)) :
if sf:
posis = (posis%1.)@cell # convert xsu to xs first
else:
posis = (posis - orig)%np.linalg.norm(cell,axis=1)
posis = (posis - orig)%cell.sum(axis=0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 0th dim of cell is the frame. cell.sum(axis=0) sums the cell tensors of all frames. It doesn't make sense to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The safe_get_posi function handles one frame each time. When the safe_get_posi function is called from system_data, the cell argument passed to safe_get_posi is returned from dumpbox2box function, which is always a 3*3 array.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that cell is of shape [3,3], but%cell.sum(axis=0) would not give the right wrapped coordinated in a triclinic cell.

The correct way would be:

  1. convert the physical coordinates to scaled coordinates. Notice that scale cell is a cubic
  2. wrap the scaled coordinate by posis%1.
  3. convert the scaled coordinates back to the physical coordinates.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that [x,y,z]@inv(cell) can accurately scale the physical coordinates, where inv is the inverse operation.

@amcadmus amcadmus requested a review from y1xiaoc August 3, 2021 23:50
Comment on lines +83 to +85
if not sf:
posis = (posis-orig)@np.linalg.inv(cell)# Convert to scaled coordinates for unscaled coordinates
return (posis%1)@cell # Convert scaled coordinates back to Cartesien coordinates
Copy link
Member

@amcadmus amcadmus Aug 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@y1xiaoc The scaled coordinates are converted to Cartesian coordinates, is it the expected behavior?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For orig equals to zero this should be correct.

For a Cartesian and folded coordinates (with keys x, y and z, i.e. the originally supported one) with a non-zero orig, this will change the behavior by forcing the shifted coordinate fit into the cell. For example, for a coord orginally range in (0,10) and a orig = 5, original version will lead to a coord range in (-5,5) but current version (due to the %1 operation) will warp the coord back into range (0, 10) again.

I'm not sure what is the orig parameter used for (and it seems to be ignored for scaled coordinates in both original and current version) so I cannot tell this change of behavior is problematic or not.

@amcadmus amcadmus merged commit 73ad164 into deepmodeling:devel Aug 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants