FFTW: Windows, OMP & Floats

[ax3l]

Summary

This improves the FFTW CMake find logic based on the scripts that I developed for HiPACE++/WarpX/ImpactX to find FFTW on various platforms.

It helps to find FFTW on Windows, where it is installed by default with CMake, and it uses more details from PkgConfig files on Linux/macOS, such as forwarding defines, using OpenMP acceleration if available, customizing floating point variants for SINGLE/DOUBLE precision builds (require only the variant for amrex::Real, to keep requirements minimal).

It also chooses sensible defaults to work around known FFTW build system bugs, linked inline. There are also options added to control the defaults, e.g., in package managers that use a different default (e.g., CMake FFTW install on Linux/macOS).

Additional background

See build issues in ECP-WarpX/impactx#760 (comment)

On Windows, try searching for FFTW3(f)Config.cmake files first, because:

• Installed .pc files wrongly and unconditionally add -lm
• 3.3.9: CMake .pc file adds libm unconditonally FFTW/fftw3#236

On Linux & macOS, the Autotools install tries to emulate a CMake config file, but has a bug:

• 3.3.9: Autotools lacks FFTW3LibraryDepends.cmake FFTW/fftw3#235
• Thus, by default rely on .pc files because we cannot know which install was choosen (otherwise, there is an option for it named AMReX_FFTW_SEARCH).

Checklist

The proposed changes:

• fix a bug or incorrect behavior in AMReX
• add new capabilities to AMReX
• changes answers in the test suite to more than roundoff level
• are likely to significantly affect the results of downstream AMReX users
• include documentation in the code and/or rst files, if appropriate

[ax3l]

We could make the cached plans a static variable of Plan or so...

[WeiqunZhang]

We want to support both double and float regardless of the type of amrex::Real.

[WeiqunZhang]

So could you revert that part of the changes?

[ax3l]

I think for that to work we need to make the search more general.

We can only support f and d at the same time if the FFTW library was actually built for both. Since this is a compile-time option of FFTW, we do not know until we have inspected the FFTW installation location.

[ax3l]

The FFTW install we find can be any combination of supporting one, or a subset of "float", "double", "long_double", "quad":
https://github.com/spack/spack/blob/25ce6cce47dbf863292367c8f8a08e0325fc9a64/var/spack/repos/builtin/packages/fftw/package.py#L18-L24

[ax3l]

Let's see if this does the trick :)

[WeiqunZhang]

On my system, I can see both /usr/lib/x86_64-linux-gnu/libfftw3_omp.so.3.5.8 and /usr/lib/x86_64-linux-gnu/libfftw3f_omp.so.3.5.8. But the cmake link line contains only /usr/lib/x86_64-linux-gnu/libfftw3_omp.so, not the f version.

/usr/lib/x86_64-linux-gnu/libfftw3.so /usr/lib/x86_64-linux-gnu/libfftw3_omp.so /usr/lib/x86_64-linux-gnu/libfftw3f.so

Do you know what's going on? It does not currently matter, because we are not using the threaded version.

[ax3l]

Interesting, I do call the OpenMP search for each precision. Let me check.

[ax3l]

Good catch! Fixed and verified.