Deal with platforms that don't define single-precision fftw

[JBlaschke]

Some platforms (eg. Cori GPU at NERSC) don't provide single-precision fftw -- this RP doesn't add -lfftw3f if the corresponding *.so isn't at $FFTW_DIR

[lu1and10]

Seems the ci breaks for all the systems.
@JBlaschke Is there other way to detect single precision FFTW lib available(not just FFTW_DIR)?
Current setup does not assume $FFTW_DIR is defined, the FFTW lib may be in the system library paths, /usr/local/lib, etc...
Or we need to change the makefile to have $FFTW_DIR defined by default or supplied by the user.

[JBlaschke]

Yea @lu1and10 -- I just put some more guards into the makefile to skip the single-precision translation units

[JBlaschke]

It looks like the problem is that the tests use the single-prec code ... If someone wants to put #ifdefs around those, please go ahead. Otherwise I'll fix that once I wrap up some other things.

[ahbarnett]

Hmm, I didn't know that single-prec FFTW was something that could be missing from a FFTW distribution! I guess libfftw3-single3 could be absent even though usually part of libfftw3. Looks like we'd need a new NOSINGLE makefile build flag which would:

• not link single fftw in the LIBS
• not compile (or at least not attempt to link) any tests or examples with the SINGLE flag. This could be just removing OBJSF from OBJSD on l.114
• not run any single-prec tests... but would that have to propagate to all language interfaces too?

We made an effort to group double vs single tasks in the makefile. So the makefile alone wouldn't be too hard, but would add another layer of messiness - plus it's the language interfaces I worry about. There are 5 language interfaces, each with own examples, and each has to be changed to have a NOSINGLE option. Also, would running a NOSINGLE build become part of the CI test, and/or our own makefile tests too? This is getting tricky, but that's what PRs are for I guess...:)

[JBlaschke]

@ahbarnett I have picked this up again, as we're running into this from time-to-time.

I used the terminology from the FFTW3 docs: https://www.fftw.org/fftw3_doc/Installation-on-Unix.html where they use ./configure --enable-single to build the single precision symbols. So I introduce ENABLE_SINGLE (default ON) which builds the single-precision symbols and test only when ENABLE_SINGLE=ON. Since the default is ON already, nothing should change on our average system, and we (at NERSC, etc) can simply set ENABLE_SINGLE=OFF make libs

I have abandoned the automatic detection for single-precision libraries because: i) it would result in some nasty make code; ii) some systems might have multiple installs of FFTW3 (and makefiles that are too smart for their own good are usually a bad idea).

In the spirit of point (ii) I am also adding FFTW_DIR and FFTW_INC to allow non-standard locations for FFTW3 without needing to mess with the CFLAGS, CXXFLAGS, and FFLAGS.

I tested the no-single version and it seems to work fine. The C and Fortran interfaces should be fine. I can work on the python language interface (and the Julia wrappers are defined separately anyway, so we should be able to leave those as-is). That leaves Matlab -- I don't know Matlab all that well (only from my BSc days -- and that was many years ago) -- so I will need some help with that.

[ahbarnett]

to simplify by having makefile options to select single-prec and double-prec
and this would also switch the FFTW prec's linked.
Also do in cmake. Leave for post-v2.2.

[DiamonDinoia]

Hi, when using cmake this should be okay. Otherwise either using ducc0 or FINUFFT_FFTW_LIBRARIES=DOWNLOAD will make the code compile. Could you check? @JBlaschke

[ahbarnett]

This should be fixable via cmake or using DUCC. Also, we won't be able to maintain the extra makefile because we're about to remove the -DSINGLE compilation in favor of fully templated C++ code (de-macroize), #567