[gmx-developers] Current status FFTW-3D

[Roland Schulz]

David van der Spoel schrieb:
> Roland Schulz wrote:
>> Hi David, Carsten and Erik,
>>
>> I'd like to go ahead and start to implement the 3d FFT part.
>>
>> Do you prefer or recommend a new implemantation or is adapting an
>> existing implemantation as good? I think the 3d FFT from Steve
>> Plimpton (http://www.sandia.gov/~sjplimp/docs/fft/README.html) which
>> is used in LAMMPS could be used and is fulfilling the requirements. I
>> wouldn't recommend to use the library as shared library (compile time
>> dependences) but to simply take the code into the Gromacs CVS. This
>> is also the way it was done for LAMMPS.
>>
>> I quickly introduce myself: I studied Physics at the University of
>> Heidelberg and I'm now a UTK graduate student in the Genome Science and
>> Technology program and work in Prof. Jeremy C. Smith's group Center for
>> Molecular Biophysics at the ORNL.
>>
>> Roland Schulz (and Jeremy Smith)
>>
>
> Hi Roland,
>
> I've added a line with this info to the wiki at:
> http://wiki.gromacs.org/index.php/FFTW-3D
>
> Are you aware of any benchmarks of this code? Part of new versus
> existing code will depend on performance, even though the algorithm
> that Erik laid out on the wiki is probably very similar to this
> implementation.
I did a performance test on Jaguar (2.6 GHz dual-core Opteron, Cray
Seastar router) which is attached. I hope attachments are fine on this
list. I did it only on this cluster because I wanted to compare it to
the Eleftheriou paper and thus till 2048 and this is the only of this
size I have access to at the moment. I think it looks good in
comparison, because I didn't do any special optimization. I may be able
to do some performance tests on BlueGene to be able to do a direct
comparison.
>
> Some practical issues:
> - The library need not be shared to be separate from GROMACS, the
> default is to link statically anyway. In other words it would be good
> if it were implemented in a separate subdirectory etc, with a clear
> interface.
Yes I agree. I just meant in the last mail, that this doesn't mean we
introduce a compile time dependence people have to download separately.
> - The gromacs code (optionally) uses a subset of processors for PME.
> The new algorithm needs to be able to handle this (not difficult, but
> you can not use MPI_COMM_WORLD for instance).
I haven't checked it really yet, but at least the MPI_COMM_WORLD is not
an issue because the comm is always passed as parameter.

> - In the end we would like to have the copyright of new code, but that
> is not of immediate concern, I guess we first need a working code.
It is GPL so it shouldn't be a problem.

Roland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fft_perf.png
Type: image/png
Size: 9727 bytes
Desc: not available
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20070830/3ec1bd15/attachment.png>