Real-space FFT indices

Code transforming the 1-D index of real-space FFT arrays into 3-D indices defining the real-space position was collected into a single routine, "fft_index_to_3d", in module fft_types. Reasons:

• there were no less than 15 occurrences of the same code
• this code depends upon the distribution of data in parallel execution and was already changed (in 15 different places) once; it will be much easier to change it again next time (if any)
• this kind of operations seems to be a good target for "hiding" into a routine

IMPORTANT NOTICE: I noticed that the dimension desc%nnr is defined in the parallel case as

• desc%nnr = max( ncpx * nr3x, nr1x * nr2px * nr3px ) ! this is required to contain the local data in R and G space
• desc%nnr = max(desc%nnr,ncpx * nr3px * desc%nproc3, nr1px * nr2px * nr3px * desc%nproc2) ! this is required to use ALLTOALL instead of ALLTOALLV

All this is needed only for arrays that undergo an in-place FFT, I think, but it affects all real-space arrays via desc%nnr. An array of length 1:desc%nnr thus may contain additional space that does not correspond to any physical real-space point. Not a big deal in general: those values are set to 0, but the "offrange" variable in fft_index_to_3d may not flag correctly those cases so those do loops should run only on physical points.

There are currently 3 different limits for real-space arrays:

1. DO ir=1, desc%nr1x * desc%my_nr2p * desc%my_nr3p ...

2. nnr = dfftp%nnr; #if __MPI ir_end = MIN( desc%nnr,desc%nr1x * desc%my_nr2p * desc%my_nr3p) #else ir_end = desc%nnr #endif DO ir=1, ir_end ...

3. DO ir=1,desc%nnr ...

I suspect that 1) is correct and the simplest; 2) is more complex than needed; 3), used in Modules/qmmm.f90, might be incorrect in some unfortunate cases.

I wonder whether desc%nnr shouldn't be the true dimension of the real-space arrays and we should have another variable for the "expanded" dimensions used for in-place FFT's