Confusing "parameter flow" for the calculators

[ceriottm]

The calculators use a mix of class parameters and "compute function" parameters to define e.g. the smearing and the calculation accuracy. This is confusing and a bit clunky - it'd be better to streamline the implementation to avoid having to worry too much about (re)setting these values.

[sirmarcel]

Just to add to this, it's a huge potential foot-gun that various parts of the infrastructure now store the cell/the mesh and need to be kept updated. It may be worth thinking about converting everything into something functionally pure and then implementing caching based on these guarantees -- but I don't know yet how to best do this. I agree that this is a problem that needs to be addressed.

[PicoCentauri]

Not directly the issue but related:

While benchmarking, I found a couple of places that are slowing down the code just because we do multiplication with floats in the code. @sirmarcel already mentioned this but now I really saw it.

On top: In many places we may overcome repeating calculations by adding buffers in the init of each class to compute prefactors.

[ceriottm]

On top: In many places we may overcome repeating calculations by adding buffers in the init of each class to compute prefactors.

We have to be careful here if the prefactors depend on stuff, e.g. the smearing.

[PicoCentauri]

Good point!

this is why these points are in the correct place inside this issue. We can also update buffers if we have to, but hopefully we can avoid.