*To*: debian-astro@lists.debian.org*Subject*: Re: Inclusion of the ducc0 Python package?*From*: Martin Reinecke <martin@MPA-Garching.MPG.DE>*Date*: Fri, 3 Sep 2021 00:55:40 +0200*Message-id*: <[🔎] 15495464-0572-1faa-5899-46bef1e33b6a@mpa-garching.mpg.de>*In-reply-to*: <[🔎] 87bl5bpkrl.fsf@burgos>*References*: <0fd84702-6bfb-2741-5a99-c502c87916a6@mpa-garching.mpg.de> <[🔎] 87bl5bpkrl.fsf@burgos>

Dear Ole, thanks for your reply!

in principle, I think it would be a good addition. However, I would like to have the package having a bit more "strengtened" focus. Currently, it looks like a random collection of algorithms, which are finally hard to find for a developer.

There is a method to the madness, at least for most of the components :)

For example, if one would want to use fft, they would probably just stick to scipy and not even search for something else (unless there is a specific need). Therefore, the best here would probably be, instead of maintaining your own package, to try to include it into scipy with a pull request (on https://github.com/scipy/scipy). This would also have the advantage that you get a review of your code by other experienced people.

That's exactly how scipy got its current FFT implementation :)

Similar things can be said for the sht and the convolution algorithms.

For Healpix, I suggest to have a look into the Healpix package of astropy, https://github.com/astropy/astropy-healpix, and to help them instead of maintaining your own package.

Licensing incompatibilities again, I'm afraid.

And for the gridding algorithm, from the README it turns out that it is already integrated in wsclean, so probably it is better to cooperate with this package instead of having an extra one.

It is really better to improve the existing software packages instead to start writing your own. Aside from the often fruitful discussion during integration, the long-term maintainance is much better ensured and the visibility is much higher. And for the software community, it is easier to have a canonical place for an algorithm instead of searching a number of "Useful Code Collections". Fragmentation of software is also fragmentation of development power. Does this make sense for you? I am however happy to discuss this if (resp. where) you disagree.

Best regards, Martin

Best regards Ole Martin Reinecke <martin@MPA-Garching.MPG.DE> writes:Hi, I wanted to ask whether it might make sense to include the "ducc0" package of numerical algorithms into debian-astro. Main page: https://gitlab.mpcdf.mpg.de/mtr/ducc This package contains C++17 implementations of - a pretty fast FFT (the one used in scipy, but with several improvements) - spherical harmonic transforms (an evolution of the libsharp library) - algorithms for 4pi convolution on the sphere (an evolution of the "totalconvolver" and "conviqt" codes) - a wide-field gridding/degridding algorithm for radio astronomy - beginnings of a Python wrapper for Healpix-related functionality. with a pybind11-based Python interface. The current goal is to provide a stable Python interface, while the internal C++ interfaces are still in flux. (More details including references etc. directly in the README.md) The code has minimal external dependencies (pybind11) and is quite portable (tested on Linux x86_64, Linux arm32, MacOS x86_64 and Windows x86_64). At the moment, not many packages are explicitly depending on it, but healpy will probably switch to this as a back-end in the future, the Pixell library might use it as well, and other packages like wsclean use it by incorporating parts of its source code. Do you think this package is sufficiently "on topic" for Debian astro, and if yes, how would we proceed? Thanks, Martin

**References**:**Re: Inclusion of the ducc0 Python package?***From:*Ole Streicher <olebole@debian.org>

- Prev by Date:
**Re: Inclusion of the ducc0 Python package?** - Next by Date:
**Re: Siril is ready (again) for upload** - Previous by thread:
**Re: Inclusion of the ducc0 Python package?** - Next by thread:
**Re: Siril is ready (again) for upload** - Index(es):