Uses FFTW3 library.
(experimental) Uses PFFT library, which has to be linked.
(experimental) Uses a GPU accelerated library. This only
works if Octopus was compiled with Cuda or OpenCL support.
Should octopus optimize the FFT dimensions? This means that the mesh to which FFTs are applied is not taken to be as small as possible: some points may be added to each direction in order to get a "good number" for the performance of the FFT algorithm. The best FFT grid dimensions are given by $2^a 3^b 5^c 7^d 11^e 13^f$ where $a,b,c,d$ are arbitrary and $e,f$ are 0 or 1. (ref). In some cases, namely when using the split-operator, or Suzuki-Trotter propagators, this option should be turned off. For spatial FFTs in periodic directions, the grid is never optimized, but a warning will be written if the number is not good, with a suggestion of a better one to use, so you can try a different spacing if you want to get a good number.
The FFTs are performed in octopus with the help of FFTW and similar packages. Before doing the actual computations, this package prepares a "plan", which means that the precise numerical strategy to be followed to compute the FFT is machine/compiler-dependent, and therefore the software attempts to figure out which is this precise strategy (see the FFTW documentation for details). This plan preparation, which has to be done for each particular FFT shape, can be done exhaustively and carefully (slow), or merely estimated. Since this is a rather critical numerical step, by default it is done carefully, which implies a longer initial initialization, but faster subsequent computations. You can change this behaviour by changing this FFTPreparePlan variable, and in this way you can force FFTW to do a fast guess or estimation of which is the best way to perform the FFT.
This plan implies a longer initialization, but involves a more careful analysis
of the strategy to follow, and therefore more efficient FFTs. A side effect of the runtime
choices is that this plan can introduce slight numerical fluctuations between runs.
This is the "fast initialization" scheme, in which the plan is merely guessed from "reasonable"
assumptions. This is the default option, as it guarantees stable results
It is like fftw_measure, but considers a wider range of algorithms and often produces a
"more optimal" plan (especially for large transforms), but at the expense of several times
longer planning time (especially for large transforms).
It is like fftw_patient, but considers an even wider range of algorithms,
including many that we think are unlikely to be fast, to produce the most optimal
plan but with a substantially increased planning time.
Octopus can filter the pseudopotentials so that they no longer contain Fourier components larger than the mesh itself. This is very useful to decrease the egg-box effect, and so should be used in all instances where atoms move (e.g. geometry optimization, molecular dynamics, and vibrational modes).
Do not filter.
The filter of M. Tafipolsky and R. Schmid, J. Chem. Phys. 124, 174102 (2006).
The filter of E. L. Briggs, D. J. Sullivan, and J. Bernholc, Phys. Rev. B 54, 14362 (1996).
Normally Octopus determines automatically the type necessary for the wavefunctions. When set to yes this variable will force the use of complex wavefunctions.
Warning: This variable is designed for testing and
benchmarking and normal users need not use it.
When this variable is set to true, Octopus will perform a calculation from the beginning, without looking for restart information. NOTE: If available, mesh partitioning information will be used for initializing the calculation regardless of the set value for this variable.