Discussion: API changes after code rewrite

[bast]

To address #39 but also other smaller issues that I was unhappy with I am in the process of rewriting the code from ground up. Rewrite is basically done and will go to master soon (few small things remain). It will be written in Rust with Rust and Python bindings, available on Crates and PyPI. This fits better my current ecosystem. I think Python bindings are getting more and more important. I might reintroduce C and Fortran bindings but for the moment want to optimize for easy pip-installability, speed, and code reliability.

For numgrid 2.0 I would like to also update the API since some of the constraints of current API would then be gone. And for this I would love to hear what other people think.

Currently numgrid generates one center at a time and the motivation for this was:

• Since in the radial grid we do not know a priori how many points we get, this was a way to find out the number of points without waiting too much
• I wanted to give the caller the flexibility to parallelize over these however they wanted
• For big grids I thought this was better, but current code scales badly for the partitioning part anyway

Main question/consideration:

• Should I keep evaluating one center at a time? (internal detail is that this makes screening the Becke partitioning a bit more difficult since I don't know the basis sets on other centers)
• Or rather let the code compute the grid for the entire molecule/system? But also allowing to compute only subsets? (this would make screening a bit easier)

My feeling is that people want the whole grid in one shot most of the time and the API should optimize for that. But is that so?