-
Notifications
You must be signed in to change notification settings - Fork 24
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
ASE Backend For PBC Computation #310
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added minor comments, but the I might have a bigger lift/ask: could you write a unit test to ensure the products (i.e. offsets, src
and dst
nodes) are the same?
You could potentially do a really high level comparison: make torch_geometric.data.Data
with the edges from both algorithms, pack the data into the graphs, and just do a pmg_graph == ase_graph
assertion.
Related to #267 - possibly leading up to replacing |
I also added two tests to check for equivalence of src and dst node calculation here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for doing this!
This PR adds a flag to the
PeriodicBoundaryCondition
transform to use eitherpymatgen
orase
as a backend. The ASE backend is implemented and makes use of the NeighborList utility in ASE. This requires creating an atoms object, and specifying a cutoff distance per node. The two functionscalculate_ase_periodic_shifts
andcalculate_periodic_shifts
are quite similar, however hard to combine due to the dependency on the different backends, so they are kept separate for now.Some parameters that may have an impact on results:
NeighborList
:self_interaction
,bothways
Atoms
:pbc
For example, blindly applying PBC in x, y, and z for a structure which is not meant to be periodic in these directions may impact results.