fix grid_lebedev() due to quadpy API changes

[fs446]

We use the quadpy package for creating Lebedev spherical grids. quadpy API changed a lot meanwhile, so I tried to fixed this issue with this PR. The fix is not the nicest, since the current quadpy API handling with quadpy.u3.get_good_scheme(degree) does not fully cover all available Lebedev grids. Thus, I decided to use more lower level features calling lebedev_xxx() function directly, these functions should last longer as the upper part of the API. The API also changed the coordinate handling, it now returns cartesian coordinates. So our function must convert to az, colat, r. That's why I also copied the sph2cart and cart2sph routines from sfs toolbox into the util.py

What do you think? Thanks for suggestions and help.

[chris-hld]

I was facing the same problem. Also the API seems to change quite frequently...
Eventually I gave up on chasing them (couldn't fix to a specific old version for other reasons.).
If this is interesting, I compiled a mat file of Lebedev grids that then gets loaded and returns the correct grid. Actually, quadpy is not doing anything else last time I checked, just returning hard coded values.
Feel free to copy:
https://github.com/chris-hld/spaudiopy/blob/add74e0d05cebd83073b121d3a9aad2688506b7c/spaudiopy/grids.py#L114

[fs446]

I was facing the same problem. Also the API seems to change quite frequently...
Eventually I gave up on chasing them (couldn't fix to a specific old version for other reasons.).
If this is interesting, I compiled a mat file of Lebedev grids that then gets loaded and returns the correct grid. Actually, quadpy is not doing anything else last time I checked, just returning hard coded values.
Feel free to copy:
https://github.com/chris-hld/spaudiopy/blob/add74e0d05cebd83073b121d3a9aad2688506b7c/spaudiopy/grids.py#L114

Yeah, thanks for the hint and offer! How should we do this?

I personally like the development effort on quadpy, since it collects a lot of spatial sampling strategies for different geometries and the API evolves to a consistent handling at the moment. In long term we might not only focusing on spherical geometry and we might want to use such a package.
On the other hand, a middle term solution is to copy the code from grid.pyas suggested by chris-hld.
Or using the (really bad) coding starting this PR as a hot fix short term solution.

Any preferences here?