developers:buildsys:internals
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
developers:buildsys:internals [2016/04/06 20:07] – [Linear algebra] Yann Pouillon | developers:buildsys:internals [2024/09/02 14:26] (current) – Maryam Azizi | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Build-system | + | <WRAP important> |
+ | |||
+ | ====== Build-system | ||
===== Target audience ===== | ===== Target audience ===== | ||
- | This document | + | This document |
+ | Might contain helpful info for Abinit maintainers who want to hack the build system, and for collaborators who want to enhance the interoperability of their projects with Abinit. | ||
===== Linear algebra ===== | ===== Linear algebra ===== | ||
Line 9: | Line 12: | ||
The following simplified diagram summarizes how the build system detects linear algebra features. The starting point is colored in blue, the ending point in green, and the decision points in pink. Enhancements are framed with dashed lines. | The following simplified diagram summarizes how the build system detects linear algebra features. The starting point is colored in blue, the ending point in green, and the decision points in pink. Enhancements are framed with dashed lines. | ||
- | <ditaa> | + | {{ : |
- | / | + | |
- | |cBLU Start | | + | |
- | | + | |
- | | | + | |
- | v | + | |
- | no / | + | |
- | +--------------+cPNK with_linalg_libs? +--------------+ | + | |
- | | + | |
- | v v | + | |
- | no / | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | | Set up parameters from | | Look for flavored | / | + | |
- | | CPU and Fortran vendors| | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | / | + | |
- | |cPNK OpenMP? | + | |
- | | + | |
- | | + | |
- | | + | |
- | +-=------+--------+ | + | |
- | | Look for PLASMA | | | | + | |
- | +--------+--------+ | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | / | + | |
- | +-------+cPNK MPI? | | | + | |
- | | | + | |
- | | |yes | | + | |
- | | | | | + | |
- | | v | | + | |
- | | +----------+----------+ | + | |
- | | | Look for ScaLAPACK | + | |
- | | +---------------------+ | + | |
- | | |no | | + | |
- | | v | | + | |
- | +-------------------------------------------------------> | + | |
- | | | + | |
- | | | + | |
- | v | + | |
- | / | + | |
- | |cGRE Done | | + | |
- | +----------/ | + | |
- | </ | + | |
The driving parameter of the detection process is the // | The driving parameter of the detection process is the // | ||
+ | ===== FFT specifications ===== | ||
+ | |||
+ | <WRAP important> | ||
+ | |||
+ | I think that the release of Abinit9 gives us the opportunity to simplify a bit the treatment of the FFT libraries. We should indeed clarify the procedure that **must be followed** by users to link an external FFT library. | ||
+ | |||
+ | So far the approach has been "I have an external FFT library --> I use fft_flavor=" | ||
+ | |||
+ | Unfortunately, | ||
+ | |||
+ | In a nutshell, the (highly) recommended procedure for Abinit9 should be: | ||
+ | |||
+ | * If you are linking against the true FFTW3 library, use " | ||
+ | * If you are linking against MKL, use " | ||
+ | * Don't mix FFTW3 with MKL but use the MKL library for BLAS/ | ||
+ | |||
+ | From the programmer' | ||
+ | |||
+ | I hope I've clarified the reason why we need the -thread switch. Now let's have a look at the different FFT options available in the build system | ||
+ | |||
+ | < | ||
+ | # Supported libraries: | ||
+ | # | ||
+ | # * auto : select library depending on build environment (default) | ||
+ | # * custom | ||
+ | # * dfti : native MKL FFT library | ||
+ | # * dfti-threads | ||
+ | # * fftw3 : serial FFTW3 library | ||
+ | # * fftw3-mkl | ||
+ | # * fftw3-threads : threaded FFTW3 library | ||
+ | # * fftw3-mpi | ||
+ | # * pfft : MPI-parallel PFFT library (for maintainers only) | ||
+ | # * goedecker | ||
+ | </ | ||
+ | According to the previous discussion about threads, the four options (fftw3, fftw3-threads, | ||
+ | |||
+ | fftw3-mkl, on the other hand, is redundant with dfti and can be removed. | ||
+ | |||
+ | As concerns fftw3-mpi: in principle there are routines in Abinit in which the MPI version of FFTW3 is used to transform densities or potentials. Note, however, that as far as I know these routines are not used in the production version. My version of fftalg 312 uses a routine inspired to Goedecker' | ||
+ | |||
+ | Note that the most CPU-critical part in Abinit is represented by the FFT of the wavefunctions computed by fourwf when option == 2. Fourwf implements a rather sophisticated algorithm that performs two composite zero-padded FFTs to compute the FFT of v(r) u(r) starting from u(G). This algorithm is specific to ab-initio codes based on plane-waves and, obviously, neither FFTW3 nor DFTI-MKL provide an optimized implementation for this rather specific case. | ||
+ | |||
+ | Having said that, I think that also fftw3-mpi is redundant. If we want to maintain the possibity of calling the MPI version provided by FFTW3, we can just check at configure time whether the fftw3 libraries passed by the user provided the fftw_mpi_init symbol and then define HAVE_FFTW3_MPI | ||
+ | |||
+ | By the same token, there' | ||
+ | |||
+ | To summarize: | ||
+ | |||
+ | The following options are needed: | ||
+ | |||
+ | * dfti | ||
+ | * fftw3 | ||
+ | * fftw3-threads | ||
+ | |||
+ | while fftw3-mkl can be removed. dfti-threads can also be removed because MKL manages threading through environment variables. | ||
+ | |||
+ | fftw3-mpi can be replaced by a simple check on the presence of fftw_mpi_init that defines HAVE_FFTW3_MPI | ||
+ | |||
+ | The pfft option may be used to activate a specialized routine for fourdp but pfft should also activate HAVE_FFTW3 so that we can use the zero-padded version in fourwf. |
developers/buildsys/internals.1459973229.txt.gz · Last modified: 2016/04/06 20:07 by Yann Pouillon