Guillaume Fraux

Only 4: CHNO. EDIT: here are the structures used in the test above in ASE XYZ: [structures.xyz](https://github.com/cosmo-epfl/librascal/files/6170342/structures.xyz.txt)

So switching the code above from computing representation for all frames: ```py managers = soap.transform(frames) K_E = kernel(managers, X_pseudo, grad=(False, False)) K_E /= regularization.energies[:, np.newaxis] K_F = kernel(managers, X_pseudo, grad=(True,...

Here is a simpler standalone example (without kernels), reading from the file in https://github.com/cosmo-epfl/librascal/issues/324#issuecomment-802711381 ```py import os import psutil from rascal.representations import SphericalInvariants import ase from ase import io def...

That, or we keep stuff around that is no longer needed (I'm thinking about the cell list, I've seen issues in other software where building the neighbor list blows up...

Here is a massif profile: [massif.out.4090.txt](https://github.com/cosmo-epfl/librascal/files/6334471/massif.out.4090.txt) And the (edited) output of `ms_print --threshold=10 massif.out.4090` ``` 99.41% (3,658,807,544B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc. ->96.84% (3,564,014,336B) 0x3415D972: Eigen::DenseStorage::resize(long, long, long) [clone...

> Are you sure you're correctly accounting for the memory required by the features? Features are 8.3MiB for 434 atoms. Considering 20 neighbors per atom, the gradients need 3 x...

Continuing debugging, it looks like there are duplicated entries in the gradients: ```py import ase from rascal.representations import SphericalInvariants frames = [ ase.Atoms( "CC", cell=[4.0, 4.0, 4.0], pbc=[True, True, True],...

It looks like a lot of memory usage can be attributed to SOAP vectors normalization. Running the script from https://github.com/cosmo-epfl/librascal/issues/324#issuecomment-821246856 with `normalize = True` gives ``` memory before: 56.79 MiB...

> Does the extra memory usage (when including normalization) only happen when computing gradients? Yes. Without gradients, the used memory increases by a couple dozen of kilobytes only when normalizing,...

> What are the scenarios in which it would risk name-clashing with std::pow? For example, in https://github.com/cosmo-epfl/librascal/pull/225#discussion_r348050113, @felixmusil changed some types to make sure a call to `math::pow` was made,...