Refactoring so far has made P3M much more readable. Many thanks @jngrad
Looking at the code, I think, the folowing things are sitll open:
[ ] Disentangling general FFT info from specifics of the actual implementaiton for 3D ffts
[ ] Related: abstracting away the changed data layout after FFT
[ ] Maybe, we could use more speaking variable names in some places, e.g. replace "sm" and "fft.plan.new_mesh" by sth clearer
Details w.r.t FFT
We currently use a "hand-written" implementation for 3d FFt with MPI. This will be replaced by a library
We should split code/data strutures, that are independent of the specific implementtion.
This is, to my understanding:
The global and mpi-rank local dimensions of the charge mesh (i.e. the input to the 3d fft)
the global and mpi-3ank local indices for the charge grid in k-space (i.e., the output of the fft)
access functions for the k-space mesh (because some FFt implementation, including the one we have now, have a different memory layout after transform. E.g., the ESPResSo implementaiton swaps between col-major and row-major during transofmr)
functions for forward/backward FFT
Maybe this can be put in a base class, and specific implementations in sub-classes.
Refactoring so far has made P3M much more readable. Many thanks @jngrad
Looking at the code, I think, the folowing things are sitll open:
Details w.r.t FFT
We currently use a "hand-written" implementation for 3d FFt with MPI. This will be replaced by a library We should split code/data strutures, that are independent of the specific implementtion. This is, to my understanding:
Maybe this can be put in a base class, and specific implementations in sub-classes.