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

Change VectorExpansion that metadata is similar to rascaline #20

Open
agoscinski opened this issue Jul 19, 2023 · 0 comments
Open

Change VectorExpansion that metadata is similar to rascaline #20

agoscinski opened this issue Jul 19, 2023 · 0 comments

Comments

@agoscinski
Copy link
Collaborator

VectorExpansion has the form

TensorMap with 13 blocks
keys: l
      0
      1
        ...
      11
      12
TensorBlock
    samples (39656): ['structure', 'center', 'neighbor', 'species_center', 'species_neighbor', 'cell_x', 'cell_y', 'cell_z']
    components (1): ['m']
    properties (20): ['alpha_j', 'n']
    gradients: None

rascaline SphericalExpansionByPair has the form

TensorMap with 80 blocks
keys: spherical_harmonics_l  species_atom_1  species_atom_2
                0                  1               1
                1                  1               1
                              ...
                3                  8               8
                4                  8               8
TensorBlock
    samples (9522): ['structure', 'pair_id', 'first_atom', 'second_atom']
    components (1): ['spherical_harmonics_m']
    properties (6): ['n']
    gradients: None

where the self pairs are stored as pair_id -1. (These are two different datasets any hypers that is why number of samples and so on does not match)

  • The pair_id is a bit very specific information based on how rascaline systems work. This one I would not try to put into torch_spex
  • The cell shift information 'cell_x', 'cell_y', 'cell_z' is not really important anymore since we do the computation of the direction vectors outside of SphericalExpansion. I would just keep it for the moment, but drop it if it becomes necessary
  • Having the sparsification on the species centers and neighbors, seems to me smart to do for the nonalchemical part, but for the alchemical part it seems to make sense to keep it in the properties
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

No branches or pull requests

1 participant