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

Add computations with cell and neighbor list to the DirectPotential class #33

Merged
merged 2 commits into from
Aug 15, 2024

Conversation

PicoCentauri
Copy link
Contributor

@PicoCentauri PicoCentauri commented Aug 12, 2024

As in the title, I added the ability to pass a neighbor list and a cell to the DirectPotential class. A user can only pass a cell and neighbor shifts to take the periodic boundary conditions into account and/or additional neighbor indices to limit the pairs for which the potential should be computed.

For the background. I need this extension to subtract "intra" molecular interaction between atoms. To compute these it is mandatory to pass explicit neighbor indices and the cell.

While adding this feature I unified the distances operations and put them together with a function for computing all possible neighbor indices of a system into a file called neighbors.py. I am not super happy with the file name. If there are better ideas, I am happy to rename.

I also fixed some layout issues for the potentials.py and enabled the rendering in the docs for this file.

TODO

  • Test DirectPotentail with neighbor_indices
  • Test DirectPotentail with cell and neighbor_shifts
  • Test DirectPotentail with neighbor_indices, cell and neighbor_shifts

Copy link
Contributor

@E-Rum E-Rum left a comment

Choose a reason for hiding this comment

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

LGTM!

Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we prefer to use a relative import path (..lib) instead of an absolute path (torchpme.lib)? The absolute path looks cleaner 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.

Interesting for me other way looks cleaner. We/I prefer the relative imports (within a package) because it may make refactoring/renaming easier. If the folder structure changes you don't have to touch anything. Same for renaming.

Also, imports are shorter. You don't have to write from mypackage.XXX.YYY.ZZZ import myfunction if myfunction in the same directory just from .ZZZ import myfunction.

On top there is a style issue. isort will split the package imports into the groups seperated by an empty line:
('FUTURE', 'STDLIB', 'THIRDPARTY', 'FIRSTPARTY', 'LOCALFOLDER'). which for us will result in:

from typing import List, Optional, Union

import torch

from ..lib import InversePowerLawPotential, all_neighbor_indices, distances
from .base import CalculatorBaseTorch

if we would use absolute imports it might not be super clear what is THIRDPARTY and what is FIRSTPARTY

from typing import List, Optional, Union

import torch

from torchpme.calculators.base import CalculatorBaseTorch
from torchpme.lib import InversePowerLawPotential, all_neighbor_indices, distances

Maybe this is convincing.

@PicoCentauri PicoCentauri merged commit 7c687c1 into main Aug 15, 2024
5 checks passed
@PicoCentauri PicoCentauri deleted the direct-nl branch August 15, 2024 13:14
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.

2 participants