-
Notifications
You must be signed in to change notification settings - Fork 13
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
Queries and ideas: whether rascaline.torch.LodeSphericalExpansion() supports GPUs, and the format of the output aligned with e3nn #270
Comments
I split the GPU support discussion in a separate issue (#271). Regarding the output format: rascaline uses metatensor to store it's output, the main reason for this is that e3nn-style storage format is very wasteful, and stores a lot of explicit zeros (all the out-of-diagonal blocks in your plots). These extra explicit zeros add up and fill the RAM/GPU memory, limiting what one can do with some given hardware. For this reason, it is very unlikely we will change rascaline output format, but we can and probably should provide some ways to adapt between metatensor and e3nn. We would need two functions for this: from metatensor import TensorMap
def metatentor_to_e3nn(tensor: TensorMap) -> (Irreps, torch.Tensor):
...
def e3nn_to_metatensor(irreps: Irreps, data: torch.Tensor) -> TensorMap:
... I'm not fully familiar with e3nn, but is the For reference, metatensor format represent the |
Thank you very much for your quick reply. Regarding the above, I'm sorry I didn't describe it clearly. Let me briefly answer your confusion: the above figure shows the Wigner-D matrix in the output space; as for the dimensions of e3nn, they are very close to those of the rascaline output (block.values), except that the components of I went through the Wigner-D matrix of the output space to get an idea of the output format of rascaline and e3nn, because I wanted to try to combine the two software. For the lode set by the descriptors of the two radial channels and the highest 1st order spherical harmonic function, I surmised based on Wigner-D that its output format should be e3nn can provide two similar expressions, but with different output formats (presumably based on the figure from the original comment), especially So it might be worth considering to add an official interface to achieve compatibility between e3nn and rascaline. |
Could you share the full script you used to generate these plots?
I think (but I need to check with the script you used) that this is an artefact of how you constructed a single matrix from the block structure of metatensor TensorMap. For example, the code you initially shared lrvp = lr.keys_to_samples("species_center")
lrvp = lrvp.components_to_properties(["spherical_harmonics_m"])
lrvp = lrvp.keys_to_properties(["species_neighbor", "spherical_harmonics_l"]) Will mix You can triple check this by looking at the metadata attached to the different axes of the array:
On this front, rascaline uses the same convention as wikipedia for spherical harmonics: https://en.wikipedia.org/wiki/Spherical_harmonics#Real_form; and the ZYZ convention for Euler angles. |
Idea: the format of the output of rascaline.torch.LodeSphericalExpansion() is aligned with e3nn:
I am interested in combining rascaline.torch.LodeSphericalExpansion() with e3nn(https://github.com/e3nn/e3nn). Both methods are based on spherical harmonics and satisfy the equivariant property. However, inconsistencies in output formats arise, especially when max_radial is greater than 1.
Here is the output format of e3nn:
This is another example of e3nn:
Aligning the output formats, particularly for higher-order equivariant models, would enhance compatibility between rascaline and e3nn frameworks. Your assistance in resolving these issues would be highly beneficial, not only for my use case but also for encouraging more users to seamlessly combine these powerful frameworks.
Thank you for your consideration.
The text was updated successfully, but these errors were encountered: