Skip to content

Conversation

nHackel
Copy link
Collaborator

@nHackel nHackel commented Sep 1, 2025

As discussed in here, it is currently not possible to use the plan_nfft interface when multiple packages such as NFFT and NonuniformFFTs are loaded in the same session. The underlying issue is that both packages refer to the same function and usually have no dedicated type to dispatch one, as both want to dispatch on "normal" user array types.

This PR adds a "backend"-based selection of the NFFT plan implementation, which allows a user to chose which backend to use for a given plan_nfft call. This utilizes an additional first parameter which specifies the backend to use:

using AbstractNFFTs, NFFT, NonuniformFFTs
J, N = 8, 16
k = range(-0.4, stop=0.4, length=J)
plan_nfft(NFFT.backend(), k, N) # NFFT plan
plan_nfft(NonuniformFFTs.backend(), k, N) # Nonuniform plan

To hide this additional type from the users of upstream packages, AbstractNFFTs now features an active backend global constant, similar to how Makie allows one to switch between its backends:

using NFFT # internally calls NFFT.activate!()
J, N = 8, 16
k = range(-0.4, stop=0.4, length=J)
plan_nfft(k, N) # NFFT plan

using NonuniformFFTs
plan_nfft(k, N) # Nonuniform plan

NFFT.activate!()
plan_nfft(k, N) # NFFT plan again

This PR allows upstream packages such as LinearOperatorCollection (PR) or MRIOperators to define themselves in terms of AbstractNFFTs and use exchangable NFFT providers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant