rainwoodman/pfft-python

python binding of pfft

pfft-python

Python binding of PFFT. (github.com/mpip/pfft)

PFFT is a massively parallel Fast Fourier Transform library. For its performance, see:

https://www-user.tu-chemnitz.de/~potts/workgroup/pippig/software.php.en

This is the python binding of PFFT. The API document is at

http://rainwoodman.github.io/pfft-python/index.html

DOI of pfft-python:

PFFT is a FFT library with excellent scaling at large number of processors. We have been routinely running 10,000 ** 3 transforms on 81,000 MPI ranks as a component of the BlueTides simulation at National Center for Supercomputing Applications. This is beyond our knowledge of the limits of FFTW.

This Python binding of course cannot yet operate at such a large scale. Due to the limitations of Python packaging and moduling system. We nevertheless feel it is important to develop a python binding of PFFT to allow early exploration of a migration into scripting languages in super computing.

For example, we have build a particle-mesh solver at

http://github.com/rainwoodman/pmesh

For some leverage of the python import problem, see python-mpi-bcast at

http://github.com/rainwoodman/python-mpi-bcast

pfft-python requires mpi4py for installation.

To install from PyPI:

pip --user pfft-python

To install from git source

python setup.py install --user

PFFT, patched FFTW, and the binding are linked into one giant (6MB) shared object file. We use -fvisibility=hidden to hide the PFFT/FFTW symbols.

For Macs with Anaconda, due to this bug conda/conda#2277 one needs to make a symlink from the anaconda installation directory to /opt/anaconda1anaconda2anaconda3 .

The mental model of PFFT is similar to FFTW. We plan ahead such that the code runs and runs fast. 4 objects are involved in a FFT:

• ProcMesh : The topology / geometry of the MPI ranks. For example 4x2 or 2x4 for 8 ranks, or 250x200 for 500000 ranks.
• Partition : The partition of the FFT input / output array onto the ranks. local_i_slice, local_i_start, local_ni describes the relative offset of the input. replacing 'i' with 'o' for the output.
• LocalBuffer : The place holder of the local data storage (allocated by PFFT). use view_input() view_output() to obtain the correct numpy array of the correct shape and strides suited for either the input or the output. -- always indexed in (x, y, z) ordering.
• Plan : The PFFT plan. execute the plan to obtain the results in the output array.

A fairly complex example (testing agreement with numpy.fft) is at tests/roundtrip.py . A simpler example is example.py.

The documentation is sparse and in the source code (pfft/core.pyx), hopefully the guide here can get you started:

1. create a ProcMesh object for the communication geometry
2. create a Partition object for the data partition of the FFT mesh, in real and fourier space, both
3. allocate LocalBuffer objects for input and output. A LocalBuffer can be reused for inplace transforms.
4. create Plan objects for the transforms, with the LocalBuffer objects as scratch
5. optionally, free the scratch buffers, and create new LocalBuffer objects.
6. view the LocalBuffer objects via view_input / view_output
7. fill the LocalBuffer objects, making use of Partition.local_i_start, local_o_start which marks the offset of the local mesh. A useful function is numpy.indices. numpy.meshgrid and numpy.ogrid are also useful.
8. Apply the plans via Plan.execute with LocalBuffer objects as arguments.

Yu Feng

pfft-python's Issues

PYTHONHASHSEED

It is important that all MPI ranks carry the same PYTHONHASHSEED.
python destroys member variables in a random order determined by the hashseed. If the seed is different it is possible some MPI enabled objects goes out of scope earlier than others. This is actually a MPI related issue and shall be noted in mpi4py.

I see a strange stalling with SGI's MPT and anaconda 3.5 due to this on Plaedias

@nickhand -- I suggest you mention this in the nbodykit documentation.

Segmentation fault when R2R transform

Hello,

I just tried to adapt example/example.py into a 2R2 transform but I get a segmentation fault a the Plan object creation. It doesn't happen with other types of transforms.
Digging a little bit, the fault seems to occur line 869 of core.pyx:
cdef pfft_plan_func func = PFFT_PLAN_FUNC[self.type]
I remarked too there were no Type.R2R : Type.R2R in the dictionary 'inverse' of the method 'inverse' of class Type but I don't know if those are related.

Have you experienced such behavior?

Best regards and thank you for this great wrapper!

Simon

Linking fails on OS X El Capitan

On my OS X install (with Python provided by Homebrew), linking fails because the Python libraries cannot be found:

creating build/lib.macosx-10.11-x86_64-3.5
creating build/lib.macosx-10.11-x86_64-3.5/pfft
mpicc -shared build/temp.macosx-10.11-x86_64-3.5/pfft/core.o build/temp.macosx-10.11-x86_64-3.5/depends/lib/libpfft.a build/temp.macosx-10.11-x86_64-3.5/depends/lib/libpfftf.a build/temp.macosx-10.11-x86_64-3.5/depends/lib/libfftw3_mpi.a build/temp.macosx-10.11-x86_64-3.5/depends/lib/libfftw3.a build/temp.macosx-10.11-x86_64-3.5/depends/lib/libfftw3f_mpi.a build/temp.macosx-10.11-x86_64-3.5/depends/lib/libfftw3f.a -o build/lib.macosx-10.11-x86_64-3.5/pfft/core.cpython-35m-darwin.so
Undefined symbols for architecture x86_64:
  "_PyBaseObject_Type", referenced from:
      ___pyx_tp_new_4pfft_4core_ProcMesh in core.o
      ___pyx_tp_new_4pfft_4core_Partition in core.o
      ___pyx_tp_new_4pfft_4core_LocalBuffer in core.o
      ___pyx_tp_new_4pfft_4core_Plan in core.o
      ___pyx_tp_new_array in core.o
      ___pyx_tp_new_Enum in core.o
      ___pyx_tp_new_memoryview in core.o
      ...
  "_PyBuffer_Release", referenced from:
      ___pyx_tp_dealloc_memoryview in core.o
  "_PyByteArray_Type", referenced from:
      ___pyx_tp_new_array in core.o

and so on. The patch in #1 fixes this. I've only tested this on OS X and Linux though.

Error when importing with numpy >= 1.25

Numpy 1.25 removed nose testing support and importing pfft-python results in

ImportError: cannot import name 'Tester' from 'numpy.testing'