[CP2K:584] Re: cp2k chooses unsupported FFT grids

[Teodoro Laino]

Hi Axel,

We fixed the bug regarding this problem. Actually I have to specify  
something about that: the lengths cp2k uses as default lengths for  
fft are the internal ones and do not depend on the library chosen.  
Why that?

I remember we decided to go for this behavior to avoid the case in  
which two different FFT libraries on two different machines would  
give different numbers with the same input file (this could puzzle  
few non-PW users). At least now the program will stop and you've to  
enable the keyword:

http://cp2k.berlios.de/input/ 
InputReference~__ROOT__~GLOBAL.html#EXTENDED_FFT_LENGTHS

and the lengths chosen will be the specific ones for each FFT library.

Please, do an update and test your input file enabling this keyword.  
(my test that was reproducing the problem with these fixes works now).
Let me know if you have still any problem.

A presto!
Teo

On 15 Jan 2008, at 19:56, Axel wrote:

>
>
>
> On Jan 15, 6:35 pm, Juerg Hutter <hut... at pci.uzh.ch> wrote:
>> Hi Axel
>>
>> do I get it right:
>> CP2K would like to use 100, but because of the FFT length
>> table (see fftessl_lib.F) is forced to use 110. However,
>> your ESSL library complains that 110 is not a valid transform length.
>
> hello juerg,
>
> no. cp2k tries to use 100, but ESSL tells it to not use it
> and then suggests to use 110 instead.
>
> my first post was wrong. i misread the error message.
>
> it looks as if the get_length() subroutine is not called.
> i just added a print statement there and it does not show up.
> hmm...
>
> cheers,
>    axel.
>
>
>
>>
>> The table in fftessl_lib.F was copied from the ESSL manual.
>>
>> seehttp://publib.boulder.ibm.com/infocenter/clresctr/vxrx/ 
>> index.jsp?topi...
>>
>> where it says
>> Acceptable Lengths for the Transforms
>> Use the following formula to determine acceptable transform lengths:
>> n = (2h) (3i) (5j) (7k) (11m)    for n <= 37748736
>>
>> where:
>> h = 1, 2, ..., 25
>>   i = 0, 1, 2
>>   j, k, m = 0, 1
>>
>> so 110 is a valid length.
>> Do you have some very special version of ESSL?
>>
>> greetings
>>
>> Juerg
>>
>> ----------------------------------------------------------
>> Juerg Hutter                   Phone : ++41 44 635 4491
>> Physical Chemistry Institute   FAX   : ++41 44 635 6838
>> University of Zurich           E-mail: hut... at pci.uzh.ch
>> Winterthurerstrasse 190
>> CH-8057 Zurich, Switzerland
>> ----------------------------------------------------------
>>
>> On Tue, 15 Jan 2008, Axel wrote:
>>
>>> hi again,
>>
>>> small correction, after sprinkling a few debug prints into the  
>>> code i
>>> found,
>>> that the code picks a dimension of 100 and then suggests to use 110.
>>> my bad, i'm too used to fftw grids obviously. however, the main
>>> problem
>>> remains. 100 is not listed as supported by fftessl, so how come  
>>> it can
>>> select it?
>>> with -O2 i'm not exactly using an aggressive optimization...
>>
>>> puzzled,
>>>    axel.
>>
>>> On Jan 15, 4:49 pm, Axel <akoh... at gmail.com> wrote:
>>>> hi!
>>
>>>> i'm trying to run the 32 water quickstep benchmark on an IBM  
>>>> machine
>>>> with ESSL and the job stops with an error message, that a  
>>>> dimension of
>>>> 110 is not supported. while the error makes sense (essl does not
>>>> support
>>>> roots of 11, only fftw), shouldn't the code pick a compatible  
>>>> number?
>>>> i specified FFTESSL explicitely as preferred library and it is
>>>> compiled in
>>>> (or else, there would be no error)...
>>
>>>> any suggestions?
>>
>>>> cheers,
>>>>     axel.
> >