Segmentation fault in SphericalCovariants for covariant_lambda=0

[bananenpampe]

Hello everyone,

calling the SphericalCovariants function with covariant_lambda=0 results in a segmentation fault.

#load some wrapped training structures

hypers = {"soap_type": "LambdaSpectrum",
          "interaction_cutoff": 3,
          "radial_basis": "GTO",
          "max_radial": 9,
          "max_angular": 9,
          "gaussian_sigma_constant": 0.3,
          "gaussian_sigma_type":"Constant",
          "cutoff_function_type":"ShiftedCosine",
          "cutoff_smooth_width": 0.5,
          "normalize": True,
          "cutoff_function_parameters":dict(rate=1,scale=3.5,exponent=4),
          "covariant_lambda":0
         }

calculator = SphericalCovariants(**hypers)
X_train = calculator.transform(train_structures).get_features(calculator)

The relevant gdb output is:

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x00007fffcc99365b in void rascal::CalculatorSphericalCovariants::compute_impl<(rascal::internal::SphericalCovariantsType)0, 0, rascal::AdaptorStrict<rascal::AdaptorCenterContribution<rascal::AdaptorNeighbourList<rascal::StructureManagerCenters> > > >(std::shared_ptr<rascal::AdaptorStrict<rascal::AdaptorCenterContribution<rascal::AdaptorNeighbourList<rascal::StructureManagerCenters> > > >) ()

[agoscinski]

are you (@max-veit @Luthaf) okay with a fix to throw error when covariant_lambda=0? I doubt that anyone will fix the real underlying error. We can refer to the python implementation which seems to be now the standard (? @curiosity54). It's also not horrible slow if the number structures is decently large.

[Luthaf]

We also discussed removing SphericalCovariants altogether at some point, suggesting users to use the Python-only version when then try to import it.