[CP2K-user] [CP2K:19343] FFT problems with large unit cell

[Léon Luntadila Lufungula]

Dear Prof. Hutter,

First off, my apologies for writing your surname incorrectly. I was so 
focussed on not forgetting the umlaut that I seem to have placed it on the 
wrong part of your name.

Second, changing the source might be an option for local calculations but 
implementing this change on our HPC cluster is very cumbersome as I have 
discovered a while back when doing something similar with Quantum ESPRESSO. 
Therefore, I think I'll try forcing a common grid for the troublesome 
calculations, but I am not sure how to do this in practice. I searched the 
mailing list and documentation for common grid size, but could not find the 
correct option. Could you point me in the right direction for this?

Kind regards,
Léon

P.S. Thanks for the descriptive answers, they really help me understand the 
program and how to improve my input files!

On Tuesday, 10 October 2023 at 13:23:37 UTC+2 Jürg Hutter wrote:

> Hi
>
> the wavelet solver uses its own FFT library. The calculation then requires 
> that
> the number of grid points is allowed for both, the FFT library used in 
> CP2K and
> in the wavelet solver code. For smaller lengths that is no problem. For 
> larger ones the FFTSG is not available and FFTW3 might use different roots.
>
> Possible solution (I haven't done any tests):
> Change in src/pw/fft/fftw3_lib.F
>
> maxn_threes = 6
> maxn_fives = 5
> maxn_sevens = 0
> maxn_elevens = 0
> maxn_thirteens = 0
>
> If this doesn't work for some a/b/c settings, force a common grid size in 
> the input.
>
> regards
> JH
>
> PS: Please check the correct writing of my name, thank you.
>
> ________________________________________
> From: cp... at googlegroups.com <cp... at googlegroups.com> on behalf of Léon 
> Luntadila Lufungula <Leon.luntad... at uantwerpen.be>
> Sent: Tuesday, October 10, 2023 11:10 AM
> To: cp2k
> Subject: Re: [CP2K:19336] FFT problems with large unit cell
>
> Dear Prof. Hütter,
>
> I quickly want to summarize the errors I've had in hope that you can 
> provide some answers as to why these happen and how I can fix them.
>
> So I ran some calculations of a 1x4x3 anatase (101) slab with different 
> vacuum thicknesses [a = 10 Å, b = 20-70 Å, c = 15 Å (XZ periodicity for 
> wavelet solver)] and tried the following combinations of FFT libraries 
> which resulting in the errors stated below:
>
> 1) FFTSG + EXTENDED_FFT_LENGTHS: fails for b = 70 Å with an "Index to 
> radix array not found"-error
> 2) FFTW3 + EXTENDED_FFT_LENGTHS: fails at every value of b with "the FFT 
> in the x direction is not allowed; n01 dimension 175"-error
> 3) FFTW3: fails for b = 70 Å with an "Index to radix array not found"-error
>
> From what you've told me I plan on going with the FFTW3 library from now 
> on, but it does still fail with a sufficiently large box when 
> EXTENDED_FFT_LENGTHS is disabled, but enabling this option makes the 
> problem even worse as then the calculation fails no matter the size of the 
> unit cell...
>
> So my question is why does the FFTW3 library give an Index error when you 
> stated that it does not have an upper limit and why then does enabling the 
> EXTENDED_FFT_LENGTHS result in the other error stated above?
>
> Best regards,
> Léon
>
> On Wednesday, 4 October 2023 at 09:57:02 UTC+2 Léon Luntadila Lufungula 
> wrote:
> Dear Prof. Hütter,
>
> Thanks for the suggestion I'll switch to FFTW3 then, but I do still have 
> one question about using FFTW3. Why do I get the error "the FFT in the x 
> direction is not allowed n01 dimension 175" when switching from 
> FFTSG/EXTENDED to FFTW3/EXTENDED, while I get an "Index to radix array not 
> found." error when switching of EXTENDED_FFT_LENGHTS?
>
> Kind regards,
> Léon
>
>
>
> On Wednesday, 4 October 2023 at 09:35:36 UTC+2 Jürg Hutter wrote:
> Hi
>
> there is an upper limit for the FFT length for the FFTSG library (1024).
> I would switch to FFTW3 where no such limit exists.
>
> regards
> JH
>
> ________________________________________
> From: cp... at googlegroups.com <cp... at googlegroups.com> on behalf of Léon 
> Luntadila Lufungula <Leon.luntad... at uantwerpen.be>
> Sent: Tuesday, October 3, 2023 2:06 PM
> To: cp2k
> Subject: [CP2K:19284] FFT problems with large unit cell
>
> Dear all,
>
> I am running some tests with long chain adsorbates on a TiO2 slab and I'm 
> running into some problems with the FFT libraries. I initially had the 
> FFTSG set as preferred library, because the manual stated that "The use of 
> PREFERRED_FFT_LIBRARY FFTSG is required" when using the WAVELET solver. 
> However, I just read in this post<
> https://groups.google.com/g/cp2k/c/QEveWI7UqV0> from Prof. Hütter that 
> you can use the FFTW3 library in combination with the WAVELET solver and I 
> already read several times that using this library is generally faster 
> compared to the internal FFTSG one. I also already had to enable the 
> EXTENDED_FFT_LENGTHS option for calculations with smaller (10x10x30) cells 
> as I ran into some "Index to radix array not found."-errors.
>
> Now, with these long adsorbates I have a cell of around 10 x 15 x 60 Å and 
> the combination of FFTSG/EXTENDED_FFT_LENGTHS again gives "Index to radix 
> array not found."-errors, while switching to FFTW3/EXTENDED_FFT_LENGHTS 
> says that "the FFT in the x direction is not allowed n01 dimension 175".
>
> So I have two questions:
> 1) Is it possible to calculate such a large cell without getting these FFT 
> errors or is it just too large?
> 2) Should I switch to FFTW3/EXTENDED_FFT_LENGTHS to speed up my 
> calculations or is it fine to continue with FFTSG/EXTENDED_FFT_LENGTHS?
>
> Hopefully someone can help me out with this problem.
>
> All the best,
> Léon
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "cp2k" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to cp2k+uns... at googlegroups.com<mailto:cp2k+uns... at googlegroups.com
> >.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/cp2k/38650355-0f22-4606-82bb-16a670bc8619n%40googlegroups.com
> <
> https://groups.google.com/d/msgid/cp2k/38650355-0f22-4606-82bb-16a670bc8619n%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "cp2k" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to cp2k+uns... at googlegroups.com<mailto:cp2k+uns... at googlegroups.com
> >.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/cp2k/e97d9f8a-ac3e-4cf6-adf7-4e32cfc9010fn%40googlegroups.com
> <
> https://groups.google.com/d/msgid/cp2k/e97d9f8a-ac3e-4cf6-adf7-4e32cfc9010fn%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
>

-- 
You received this message because you are subscribed to the Google Groups "cp2k" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cp2k+unsubscribe at googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/a3612a0e-35e9-45ca-9664-eed48a6dd7efn%40googlegroups.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20231010/2ef257b9/attachment.htm>