Oh, yes, the current fortran-lang/fftpack is based on netlib/fftpack4.0 (public domain).
We also have a nacr/fftpack5.1 (FFTPACK license, look like MIT and BSD-3, see comment and FFTPACK5 (the “Software”) License), which natively supports multi-dimensional FFT, but gfortran compilation requires --fallow-argument-mismatch (see Build failure with gfortran 10 · Issue #123 · NCAR/ncl · GitHub) (This issue will be solved by that fpm supports native flag settings, see my discourse help).
My initial idea was to develop certik(netlib)/fftpack4.0 and nacr/fftpack5.1, first do fftpack4.0 and then fftpack5.1. I do not involve john/fftpack5.1 by default, it uses the GPL license, which may be less friendly to users.
But in fact we better maintain only one fortran-lang/fftpack?
My question is: do we need to develop based on nacr/fftpack5.1? Or let’s leave it to time, let’s finish fftpack4.0 first.
My thoughts:
First, I will try my best to improve fftpack4.0, and when it has modern features, I am willing to see whether it is necessary to maintain fftpack5.1 (may consider the needs of multi-dimensional fft), if necessary, I will hope to achieve the modern features of fftpack5.1 in another branch (I believe there is fftpack4.0 experience, this work is not difficult, it is just a matter of time). In general, the two fftpacks try to keep the same modern interface.
P.S.
-
netlib/dfftpack1.0(fftpack4.0) (License : public domain)
Fortran77 -
nacr/fftpack5.1 (License: look like MIT and BSD-3, see comment)
Fortran77 -
John Burkardt/fftpack5.1 (License: LGPL/GPL)
Fortran90 from nacr/fftpack5.1 -
QcmPlab/SciFortran (License: shall be GPL)
From John Burkardt fortran90, fftpack5.1 with interface. -
keurfonluu/FFTPack (License: shall be GPL)
From John Burkardt fortran90, fftpack5.1 with interface. -
jlokimlin/modern_fftpack (License: FFTPACK license look like MIT and BSD-3 ?)
Fortran90, look like from nacr/fftpack5.1 ?