Future directions for CG iterations

[jwa7]

The first 'iteration' of the Python redesign is starting to converge - see #237. In a rough order of chronology and/or complexity, the next steps to be tackled in future PRs are as follows:

To Do - Functionality

• [ ] Implement correlate_tensors:

  def correlate_tensors(
  tensor_1: TensorMap,
  tensor_2: TensorMap,
  angular_cutoff: Optional[int] = None,
  selected_keys: Optional[Labels] = None,
  ) -> TensorMap:
  """
  Performs the Clebsch Gordan tensor product of two TensorMaps that correspond
  to densities or density correlations. Returns a new TensorMap corresponding
  to a higher correlation-order descriptor.
  
  The two input tensors can be single- or multi-center, and of arbitrary (and
  different) correlation order, but must contain the same samples.
  """

• [ ] Ensure torch dispatch works and make the CG code torchscript-able (with @Luthaf)
• [ ] Support CG products of gradients (with @PicoCentauri and @Luthaf)
• [ ] Speed up wrapper code (i.e. everything that isn't the tensor product operation). Line profiling shows that the pre-calculation (and caching for subsequent but separate calculations) of the components and properties might be a good place to start (with @frostedoyster)
• [ ] Run systematic benchmarking on sparse vs dense vs sparse w/ Mops. Define when in general it is best to use one over the others, and dynamically change the default based on the input system (with @frostedoyster)
• [ ] Metadata such as "order_nu" should be associated with the TensorMap and not in the keys - awaiting functionality in metatensor
• [ ] Extend to combinations of tensors with different samples (with @DivyaSuman14 and @curiosity54)
• [ ] Later down the line: customizable and arbitrary (non)linear transformations at each iteration (with @agoscinski, thesis dependent)

To Do - Documentation

• [ ] Include concise but complete explanations of sign conventions (i.e. Sph Harms, Condon Shortley, etc) both in reference to the CG cache implemented (i.e. using wigners) and compared to other rascaline Calculators --> i.e. PowerSpectrum updated to include (-1)^l factor
• [ ] Different types of documentation, see https://www.writethedocs.org/videos/eu/2017/the-four-kinds-of-documentation-and-why-you-need-to-understand-what-they-are-daniele-procida/ (thanks @Luthaf ). Particularly important for CGs where there is a lot going on with maths, conventions, and design choices.

[Luthaf]

• [ ] function that compute metadata should not need to allocate memory for the data arrays. We should have a new EmptyArray class in Python's metatensor API that just track the size of the array but is not allocating memory.

[Luthaf]

• [x] the current tests are quite slow, we should see how to make them faster!

tox -e all-deps -- python/rascaline/tests/utils/clebsch_gordan.py

<snip ...>

27 passed in 77.57s

This should not take more than ~10s. All the other Python tests together take around 10s.

I would use smaller datasets/lmax/... to make sure there tests are not becoming a nuisance when developing other parts of the code.

[jwa7]

• [ ] the current tests are quite slow, we should see how to make them faster!

tox -e all-deps -- python/rascaline/tests/utils/clebsch_gordan.py

<snip ...>

27 passed in 77.57s

This should not take more than ~10s. All the other Python tests together take around 10s.

I would use smaller datasets/lmax/... to make sure there tests are not becoming a nuisance when developing other parts of the code.

@Luthaf Noted! Fixed in #266

[jwa7]

• [ ] Agree on k_{x} numbering convention between the cartesian_to_spherical routine(s) and CG utils
• [ ] Generalised and re-factored CG tensor product routines, to be done in #316
• [ ] Implement high level CG-based calculators for the main use cases, fully documented and tested