# Proposal: moving fftpack under fortran-lang

**URL:** <https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711>\
**Category:** Uncategorized\
**Created:** [August 17, 2021, 3:15pm UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711 "2021-08-17T15:15:48Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [August 17, 2021, 3:15pm UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/1 "2021-08-17T15:15:48Z")

</div>

We have discussed in the past the possibility of maintaining packages under fortran-lang at GitHub.

I would like to propose one such move: [https://github.com/certik/fftpack](https://github.com/certik/fftpack) → [https://github.com/fortran-lang/fftpack](https://github.com/fortran-lang/fftpack)

@zoziha has done a great job modernizing it by adding `fpm` support, CI, modern interfaces, etc. So it would be at least he and I maintaining it. And we are hoping others would join also.

Let me know what you think.

---

<div class="post-metadata">

**Author:** ![zoziha](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zoziha/32/582_2.png) [@zoziha](https://fortran-lang.discourse.group/u/zoziha)\
**Post date:** [August 17, 2021, 3:32pm UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/2 "2021-08-17T15:32:25Z")

</div>

Fast Fourir Transform (FFT) is a well-known and practical algorithm. `fftpack` is the native fft implementation of `Fortran` stored in `netlib`. I believe we have the need to maintain and use it. My original intention was to make `fftpack` easier-to-use when `fortran-lang` was rebuilding the Fortran community. We have some APIs we can refer to:

1. [keurfonluu/FFTPack: FFTPack aims to provide an easily usable package of functions using FFTPack library (Fortran 77). (github.com)](https://github.com/keurfonluu/FFTPack)
2. [Legacy discrete Fourier transforms (scipy.fftpack) — SciPy v1.7.1 Manual](https://docs.scipy.org/doc/scipy/reference/fftpack.html)
3. There is some more information here (some are outdated):  
[To update the `fftpack` package · Issue #1 · certik/fftpack (github.com)](https://github.com/certik/fftpack/issues/1) ;  
[add `fftpack` package by zoziha · Pull Request #40 · fortran-lang/fpm-registry (github.com)](https://github.com/fortran-lang/fpm-registry/pull/40#issuecomment-837038091).

@certik I still have 2 tasks waiting to be submitted. Please wait until I finish these 2 tasks **today or tomorrow** before we migrate `certik/fftpack` to `fortran-lang/fftpack`.

---

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [August 17, 2021, 3:43pm UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/3 "2021-08-17T15:43:58Z")

</div>

Yes of course, we’ll wait.

I also have a modern Fortran reimplementation of FFTPACK here: [hfsolver/fourier.f90 at master · certik/hfsolver · GitHub](https://github.com/certik/hfsolver/blob/master/src/fourier.f90), but that should go into a separate package. For `fortran-lang/fftpack` I would like to preserve the original algorithm, for benchmarking and reference.

---

<div class="post-metadata">

**Author:** ![hsnyder](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hsnyder/32/747_2.png) [@hsnyder](https://fortran-lang.discourse.group/u/hsnyder)\
**Post date:** [August 17, 2021, 6:23pm UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/4 "2021-08-17T18:23:09Z")

</div>

Yes please! I haven’t actually _used_ the version at certik/fftpack yet, but I’ve looked at the interface (as explained in the new spec files) and I like what I see. I am definitely in favour of bringing this into fortran-lang, and while I’m rather overloaded right now, in principle I’m willing to help maintain it in the future.

---

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [August 17, 2021, 7:43pm UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/6 "2021-08-17T19:43:24Z")

</div>

Yes, that’s exactly what I would like to do.

---

<div class="post-metadata">

**Author:** ![zoziha](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zoziha/32/582_2.png) [@zoziha](https://fortran-lang.discourse.group/u/zoziha)\
**Post date:** [August 18, 2021, 4:56am UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/8 "2021-08-18T04:56:55Z")

</div>

> [@kargl](#):
>
> I cannot find any information  
> with regards to an internal API for stdlib

 ![image](https://global.discourse-cdn.com/free1/uploads/fortran_lang/original/1X/75b573f1e822c31d938937224bcd35a3692f4efc.png)

API-doc website: [Fortran-lang/stdlib](https://stdlib.fortran-lang.org/) or maybe [Contributing and specs – Fortran-lang/stdlib](https://stdlib.fortran-lang.org/page/index.html)？

---

<div class="post-metadata">

**Author:** ![hsnyder](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hsnyder/32/747_2.png) [@hsnyder](https://fortran-lang.discourse.group/u/hsnyder)\
**Post date:** [August 18, 2021, 5:15am UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/10 "2021-08-18T05:15:26Z")

</div>

I think it’s just a miscommunication over exactly what is meant by ‘internal API for stdlib’ (I’m actually not clear either)

---

<div class="post-metadata">

**Author:** ![awvwgk](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/awvwgk/32/154_2.png) [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)\
**Post date:** [August 18, 2021, 6:18am UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/12 "2021-08-18T06:18:42Z")

</div>

You are right, the kind parameters in stdlib are one of the two modules which are currently undocumented in the internal API documentation. It’s a low-hanging fruit for a new contributor to fix or a straight-forward task for the existing developers to take care of, if nobody takes this up, I’ll send a patch by end of the week.

---

<div class="post-metadata">

**Author:** ![awvwgk](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/awvwgk/32/154_2.png) [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)\
**Post date:** [August 18, 2021, 10:19am UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/14 "2021-08-18T10:19:53Z")

</div>

I opened an issue at stdlib to continue this discussion

> <https://github.com/fortran-lang/stdlib/issues/485>
>
> Documentation for the kinds available from \`stdlib\_kinds\` is currently missing.

And there is already support to fix this short-coming in stdlib.

---

<div class="post-metadata">

**Author:** ![hsnyder](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hsnyder/32/747_2.png) [@hsnyder](https://fortran-lang.discourse.group/u/hsnyder)\
**Post date:** [August 18, 2021, 5:42pm UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/16 "2021-08-18T17:42:46Z")

</div>

> [@kargl](#):
>
> It is difficult to use `sp` , `dp` , and `qp` to write a generic interface for  
> a routine to be included in Fortran stdlib or one’s own project that  
> may consume Fortran stdlib.
> 
> Why? Because, `real128` may be `-1` or `-2` . Note, I am here assuming  
> `real32` maps to default real kind and `dp` maps to `double precision` . In  
> theory, those could also be either `-1` or `-2` . So, a user of Fortran stdlib  
> needs to data mine stdlib\_kinds to determine if `sp` , `dp` , and `qp` are  
> validate kind type parameters.

Ah, _now_ I see the issue. Thank you. So if we generate the list of kinds at build time, and then use that list to generate our generic implementations of stdlib functions, how would you propose handling symbolic shorthands like `dp`, etc? Should we just omit those for the purpose of stdlib, and assume users of the library will define their own based on whatever kinds they need?

And just out of curiosity, the possible five real kinds you’re referring to… are are they the common 32/64/128 bit kinds, plus 16 bit and 80 bit?

---

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [August 18, 2021, 8:13pm UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/18 "2021-08-18T20:13:41Z")

</div>

Thanks @kargl for the feedback. I think what you are suggesting makes sense. Please keep the messages up for a while until we document your suggestion.

@zoziha, anything else you want to do before we move fftpack under fortran-lang?

---

<div class="post-metadata">

**Author:** ![zoziha](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zoziha/32/582_2.png) [@zoziha](https://fortran-lang.discourse.group/u/zoziha)\
**Post date:** [August 19, 2021, 12:08am UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/19 "2021-08-19T00:08:37Z")

</div>

> [@certik](#):
>
> @zoziha, anything else you want to do before we move fftpack under fortran-lang?

No sir. ❤

---

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [August 19, 2021, 1:13am UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/20 "2021-08-19T01:13:59Z")

</div>

Ok, I just moved it under fortran-lang! Here is the repository:

[GitHub - fortran-lang/fftpack: double precision version of fftpack](https://github.com/fortran-lang/fftpack)

---

<div class="post-metadata">

**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\
**Post date:** [August 19, 2021, 1:55am UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/21 "2021-08-19T01:55:52Z")

</div>

The Fast Fourier Transform section of [Fortran code on GitHub](https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md) lists the following repos. [Modern\_fftpack](https://github.com/jlokimlin/modern_fftpack) has 12 stars.

[2DECOMP&FFT](https://github.com/BenMql/2decomp_emptyFourierFourier): scalable library for Fourier transforms, derived from 2decomp&fft, by BenMql. Compatible with in-core Chebyshev transforms.

[ffte](https://github.com/certik/ffte): computes Discrete Fourier Transforms of 1-, 2- and 3- dimensional sequences of length (2^p) _(3^q)_ (5^r).

[fftlog-f90](https://github.com/coccoinomane/fftlog-f90): extended Fortran 90 version of the FFTLog code by Andrew Hamilton to convolve a tabulated function with a Bessel functions, by coccoinomane

[fft-overlap](https://github.com/dappelha/fft-overlap): efficient implementations of ffts on multiple GPUs and across multiple nodes, by dappelha. Overlapping data transfer on multiple levels.

[fftpack](https://github.com/fortran-lang/fftpack): double precision version of original fftpack, from fortran-lang

[FFTPack](https://github.com/keurfonluu/FFTPack): easily usable package of functions using wrapping the Fortran 77 FFTPack library, by keurfonluu

[modern\_fftpack](https://github.com/jlokimlin/modern_fftpack): Fortran 2008 library of fast Fourier transforms – an object-oriented modernization of NCAR’s FFTPACK5.1., by jlokimlin

[nufft](https://github.com/biotrump/nufft): code for the 1D, 2D and 3D non-uniform FFTs, from biotrump

---

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [August 19, 2021, 2:21am UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/22 "2021-08-19T02:21:56Z")

</div>

@Beliavsky thanks for the list. I also wrote a modern Fortran version of fftpack here: [hfsolver/fourier.f90 at master · certik/hfsolver · GitHub](https://github.com/certik/hfsolver/blob/master/src/fourier.f90). One has to be careful with performance, for example allocating memory in the inner loop: [modern\_fftpack/complex\_forward\_1d.f90 at 6909d44988925dcae1ee478c06be31e5605d3974 · jlokimlin/modern\_fftpack · GitHub](https://github.com/jlokimlin/modern_fftpack/blob/6909d44988925dcae1ee478c06be31e5605d3974/src/complex_forward_1d.f90#L303) might slow things down. For that reason, I think the best way forward is to “preserve” the original code as much as possible, for benchmarking and reference purposes, but do the following changes:

- add modern Fortran interfaces
- fpm, CI, … (mostly done)
- possibly move from fixed form to free form; and move the global subroutines to modules
- add single precision version
- add benchmarks

But changes like rewriting the complex passes to use more modern Fortran as I have done here: [hfsolver/fourier.f90 at b4c50c1979fb7e468b1852b144ba756f5a51788d · certik/hfsolver · GitHub](https://github.com/certik/hfsolver/blob/b4c50c1979fb7e468b1852b144ba756f5a51788d/src/fourier.f90#L201) should be done in a separate library.

Such ash `fft.f`. 🙂 / See [Naming convention for Fortran wrappers packages](https://fortran-lang.discourse.group/t/naming-convention-for-fortran-wrappers-packages/1701) /

---

<div class="post-metadata">

**Author:** ![hsnyder](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hsnyder/32/747_2.png) [@hsnyder](https://fortran-lang.discourse.group/u/hsnyder)\
**Post date:** [August 19, 2021, 3:16am UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/23 "2021-08-19T03:16:38Z")

</div>

Thank you both for your work on this! I’ve already downloaded it, built it with FPM, and played around with the modern interfaces. Quick question (probably for @zoziha) - the documentation says "The contents of `wsave` must not be changed between calls of `dfftf` or `dfftb`" - can I re-use wsave in between multiple forward-backward transforms, or do I need to call `dffti` before every forward transform?

---

<div class="post-metadata">

**Author:** ![zoziha](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zoziha/32/582_2.png) [@zoziha](https://fortran-lang.discourse.group/u/zoziha)\
**Post date:** [August 19, 2021, 4:04am UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/25 "2021-08-19T04:04:59Z")

</div>

> [@Beliavsky](#):
>
> [FFTPack](https://github.com/keurfonluu/FFTPack): easily usable package of functions using wrapping the Fortran 77 FFTPack library, by keurfonluu

From my perceptual point of view, `keurfonluu/FFTPack` did a very great job. The original intention to improve `fortran-lang/fftpack` also stems from my desire to submit `keurfonluu/FFTPack` to `fpm-registry` (see [add `fftpack` package by zoziha · Pull Request #40 · fortran-lang/fpm-registry (github.com)](https://github.com/fortran-lang/fpm-registry/pull/40))

Some codes based on `fftpack5.0/5.1` may have license issues, we can keep a little conservative. (see [To update the `fftpack` package · Issue #1 · fortran-lang/fftpack (github.com)](https://github.com/fortran-lang/fftpack/issues/1))

@Beliavsky Thank you for your sharing.

---

<div class="post-metadata">

**Author:** ![zoziha](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zoziha/32/582_2.png) [@zoziha](https://fortran-lang.discourse.group/u/zoziha)\
**Post date:** [August 19, 2021, 4:31am UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/26 "2021-08-19T04:31:38Z")

</div>

> [@hsnyder](#):
>
> can I re-use wsave in between multiple forward-backward transforms, or do I need to call `dffti` before every forward transform?

I may not understand the specific details. I just transferred the instructions in the `doc` file from `netlib/fftpack` to `fftpack.md`. According to the instructions in the `doc` file, it seems best to call again, of course you can try it boldly. 😂

In addition, English is not my native language, and some writing in `fftpack.md` still needs review and improvement. (see [Add `(i)rfft/dffti/dfftf/dfftb` interface and ready to move to `fortran-lang` by zoziha · Pull Request #6 · fortran-lang/fftpack · GitHub](https://github.com/fortran-lang/fftpack/pull/6#issue-714738193)) 🤪

 ![image](https://global.discourse-cdn.com/free1/uploads/fortran_lang/original/1X/0d44c7c78a8345e43469796500d528a7828abb65.png)

---

<div class="post-metadata">

**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\
**Post date:** [August 19, 2021, 4:34am UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/27 "2021-08-19T04:34:50Z")

</div>

> [@hsnyder](#):
>
> … if we generate the list of kinds at build time, and then use that list to generate our generic implementations of stdlib functions, how would you propose handling symbolic shorthands like `dp` , etc? …

cc: @certik, @awvwgk , @aradi and team working on `stdlib`

I’ve not studied `FYPP` but this preprocessor appears to be employed actively in `stdlib`. With `FYPP`, is it possible somehow to make use of `REAL_KINDS` array named constant in `ISO_FORTRAN_ENV` in the code implementations of `algorithms` (and `containers`) in `stdlib`, rather than the current use of `REAL32`, `REAL64`, and `REAL128`, none of which are guaranteed to be supported by a conforming Fortran processor.

**Note with `REAL_KINDS` constant, a Fortran standard conforming processor can be expected to have its size be at least 2, often 3 (e.g., IFORT), a few others like `gfortran` and `NagFor` to be 4, and in the near future, some processors may have it of be of size 5 or more.** As you all know, the precise size of this array and the values of its elements would not matter to a truly generic algorithm. And this is something I hope will taken into close consideration during the Generics development with Fortran 202Y.

In the mean time, it will be good if there is a `FYPP` approach that can be used with this `REAL_KINDS` constant. For example, consider a (hypothetical and simple-minded) module toward a generic function to compute the statistical mean of rank-1 arrays:

```Fortran
module xx_stats_rank1_mean
! Module for a generic algorithm; should NOT have any dependence on REAL32, REAL64, etc.
   use, intrinsic :: iso_fortran_env, only : rk => real_kinds
   generic :: rank1_mean => rank1_mean_1, rank1_mean_2, .. rank1_mean_n ! n is the size of real_kinds
contains
   function rank1_mean_1( x ) result(mean)
      real(rk(1)), intent(in) :: x(:)
      real(rk(1)) :: mean
      mean = sum(x) / real(size(x), rk(1))
   end function rank1_mean_1
   function rank1_mean_2( x ) result(mean)
      real(rk(2)), intent(in) :: x(:)
      real(rk(2)) :: mean
      mean = sum(x) / real(size(x), rk(2))
   end function rank1_mean_2
   ..
   function rank1_mean_n( x ) result(mean)
      real(rk(n)), intent(in) :: x(:)
      real(rk(n)) :: mean
      mean = sum(x) / real(size(x), rk(n))
   end function rank1_mean_n
end module 

```

Can the macro language be setup using `FYPP` to expand out the generic function and setup the generic interface based simply on the size of `REAL_KINDS` constant array?

Thanks,

---

<div class="post-metadata">

**Author:** ![zoziha](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zoziha/32/582_2.png) [@zoziha](https://fortran-lang.discourse.group/u/zoziha)\
**Post date:** [August 19, 2021, 6:27am UTC](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711/28 "2021-08-19T06:27:09Z")

</div>

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](https://github.com/fortran-lang/fpm-registry/pull/40#issuecomment-842527064) and [FFTPACK5 (the “Software”) License](https://www2.cisl.ucar.edu/resources/legacy/fft5/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](https://github.com/NCAR/ncl/issues/123)) (This issue will be solved by that `fpm` supports native `flag` settings, see [my discourse help](https://fortran-lang.discourse.group/t/help-fallow-argument-mismatch-problem-of-basic-packages-fftpack5-1-quadpack-that-pre-support-fpm/1553)).

My initial idea was to develop `certik(netlib)/fftpack4.0` and [`nacr/fftpack5.1`](https://www2.cisl.ucar.edu/resources/legacy/fft5), first do `fftpack4.0` and then `fftpack5.1`. I do not involve [`john/fftpack5.1`](https://people.sc.fsu.edu/~jburkardt/f_src/fftpack51/fftpack51.html) 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.

1. [netlib/dfftpack1.0(fftpack4.0)](http://www.netlib.org/fftpack) (License : public domain)  
Fortran77
2. [nacr/fftpack5.1](https://www2.cisl.ucar.edu/resources/legacy/fft5) (License: look like MIT and BSD-3, see [comment](https://github.com/fortran-lang/fpm-registry/pull/40#issuecomment-842527064))  
Fortran77
3. [John Burkardt/fftpack5.1](https://people.sc.fsu.edu/~jburkardt/f_src/fftpack51/fftpack51.html) (License: LGPL/GPL)  
Fortran90 from nacr/fftpack5.1
4. [QcmPlab/SciFortran](https://github.com/QcmPlab/SciFortran) (License: shall be GPL)  
From John Burkardt fortran90, fftpack5.1 with interface.
5. [keurfonluu/FFTPack](https://github.com/keurfonluu/FFTPack) (License: shall be GPL)  
From John Burkardt fortran90, fftpack5.1 with interface.
6. **[jlokimlin/modern\_fftpack](https://github.com/jlokimlin/modern_fftpack) (License: FFTPACK license look like MIT and BSD-3 ?)**  
**Fortran90, look like from nacr/fftpack5.1 ?**

[Next page](https://fortran-lang.discourse.group/t/proposal-moving-fftpack-under-fortran-lang/1711.md?page=2)