search

metatensor / featomic

Computing representations for atomistic machine learning
http://metatensor.github.io/featomic/
BSD 3-Clause "New" or "Revised" License
44 stars 13 forks source link

CG utils: implement `ClebschGordanProduct` and refactor `DensityCorrelations` #318

Closed jwa7 closed 2 months ago

jwa7 commented 4 months ago

Implements a general TensorCorrelator class and refactors DensityCorrelations to be built on top of this. The former allows the CG tensor product of two arbitrary TensorMaps (under some constraints, mostly to do with the metadata structure as explained in the class documentation), while the latter is a convenience class specifically for computing iterative density auto-correlations.

Closes #312

📚 Documentation preview 📚: https://rascaline--318.org.readthedocs.build/en/318/

github-actions[bot] commented 4 months ago

Here is a pre-built version of the code in this pull request: wheels.zip, you can install it locally by unzipping wheels.zip and using pip to install the file matching your system

jwa7 commented 4 months ago

I somewhat agree with splitting DensityCorrelations, but think its name should still point to the fact that these are density correlations (which is important for what it's actually doing). So I'd suggest DensitySelfCorrelations DensityCrossCorrelations.

And to be fair, thinking about it, I'm not sure DensityCrossCorrelations is even useful. An EquivariantTriSpectrumByPair (for instance) is p_i x p_i x p_i x p_ij, i.e. TensorCorrelator(DensitySelfCorrelations(p_i, n_correlations=2), p_ij), right?

There isn't a use case where doing density cross correlations is actually useful, because the building block is an arbitrary body order density auto-correlation, which is then correlated with a different density (or something else).

jwa7 commented 4 months ago

So instead I think DensityCorrelations can just stay as being named like this, and the API changed to only accept a single density (not tensor and density), with the skip_redundant parameter having a single meaning where it is always valid.

DensityCorrelations then collapses back to what it always was before, a convenient way to compute density auto-correlations to arbitrary correlation order.

Luthaf commented 3 months ago

So instead I think DensityCorrelations can just stay as being named like this, and the API changed to only accept a single density (not tensor and density), with the skip_redundant parameter having a single meaning where it is always valid.

That sounds good to me!