In real space processors are organized in a 2D pattern.
Each processor owns data from a sub-set of Z-planes and a sub-set of Y-planes.
In reciprocal space each processor owns Z-columns that belong to a sub set of
X-values. This allows to split the processors in two sets for communication
in the YZ and XY planes.
In alternative, if the situation allows for it, a task group paralelization is used
(with ntg=nyfft) where complete XY planes of ntg wavefunctions are collected and Fourier
trasnformed in G space by different task-groups. This is preferable to the Z-proc + Y-proc
paralleization if task group can be used because a smaller number of larger ammounts of
data are transferred. Hence three types of fft are implemented:
!
!! ... isgn = +-1 : parallel 3d fft for rho and for the potential
!
!! ... isgn = +-2 : parallel 3d fft for wavefunctions
!
!! ... isgn = +-3 : parallel 3d fft for wavefunctions with task group
!
!! ... isgn = + : G-space to R-space, output = \sum_G f(G)exp(+iG*R)
!! ... fft along z using pencils (cft_1z)
!! ... transpose across nodes (fft_scatter_yz)
!! ... fft along y using pencils (cft_1y)
!! ... transpose across nodes (fft_scatter_xy)
!! ... fft along x using pencils (cft_1x)
!
!! ... isgn = - : R-space to G-space, output = \int_R f(R)exp(-iG*R)/Omega
!! ... fft along x using pencils (cft_1x)
!! ... transpose across nodes (fft_scatter_xy)
!! ... fft along y using pencils (cft_1y)
!! ... transpose across nodes (fft_scatter_yz)
!! ... fft along z using pencils (cft_1z)
!
! If task_group_fft_is_active the FFT acts on a number of wfcs equal to
! dfft%nproc2, the number of Y-sections in which a plane is divided.
! Data are reshuffled by the fft_scatter_tg routine so that each of the
! dfft%nproc2 subgroups (made by dfft%nproc3 procs) deals with whole planes
! of a single wavefunciton.
!
fft_type module heavily modified, a number of variables renamed with more intuitive names
(at least to me), a number of more variables introduced for the Y-proc parallelization.
Task_group module made void. task_group management is now reduced to the logical component
fft_desc%have_task_groups of fft_type_descriptor type variable fft_desc.
In term of interfaces, the 'easy' calling sequences are
SUBROUTINE invfft/fwfft( grid_type, f, dfft, howmany )
!! where:
!!
!! **grid_type = 'Dense'** :
!! inverse/direct fourier transform of potentials and charge density f
!! on the dense grid (dfftp). On output, f is overwritten
!!
!! **grid_type = 'Smooth'** :
!! inverse/direct fourier transform of potentials and charge density f
!! on the smooth grid (dffts). On output, f is overwritten
!!
!! **grid_type = 'Wave'** :
!! inverse/direct fourier transform of wave functions f
!! on the smooth grid (dffts). On output, f is overwritten
!!
!! **grid_type = 'tgWave'** :
!! inverse/direct fourier transform of wave functions f with task group
!! on the smooth grid (dffts). On output, f is overwritten
!!
!! **grid_type = 'Custom'** :
!! inverse/direct fourier transform of potentials and charge density f
!! on a custom grid (dfft_exx). On output, f is overwritten
!!
!! **grid_type = 'CustomWave'** :
!! inverse/direct fourier transform of wave functions f
!! on a custom grid (dfft_exx). On output, f is overwritten
!!
!! **dfft = FFT descriptor**, IMPORTANT NOTICE: grid is specified only by dfft.
!! No check is performed on the correspondence between dfft and grid_type.
!! grid_type is now used only to distinguish cases 'Wave' / 'CustomWave'
!! from all other cases
Many more files modified.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@13676 c92efa57-630b-4861-b058-cf58834340f0
I noticed that there is a disproportionate number of calls to sorting routine
gk_sort, computing k+G indices (igk). This is VERY DANGEROUS: the ordering of
degenerate k+G shells is unpredictable and any operation that changes k even
by even the least significant bit may lead to a slightly different ordering.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@11982 c92efa57-630b-4861-b058-cf58834340f0
command_argument_count, flush, are used everywhere instead of wrappers.
Some old versions of compilers may no longer work.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@11759 c92efa57-630b-4861-b058-cf58834340f0
- PWCOND was not compiling any more after last branch merging,
I fix it mapping old to new variables (realus), but I need someone checking it
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@10532 c92efa57-630b-4861-b058-cf58834340f0
Now all variables regarding real space grid, fft and
their parallelization are contained into the objects:
dfftp (dense grid)
dffts (smooth grid)
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@7973 c92efa57-630b-4861-b058-cf58834340f0
Further changes will follow in order to reduce dependencies and
duplicate variables (especially with dfft data structure)
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@7961 c92efa57-630b-4861-b058-cf58834340f0
1) variables nrxx, nr[123][x] moved from gvect to grid_dimensions
2) when the FFT descriptor, fdfftp, is presewnt, values contained
in the descriptor are used instead
Beware unintended side effects.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@7167 c92efa57-630b-4861-b058-cf58834340f0
smooth_grid_dimensions or in dffts%nnr is used instead. Lots of changes
but nothing substantial. Beware unintended side effects
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@7164 c92efa57-630b-4861-b058-cf58834340f0
module smooth_grid_dimensions and no longer in gsmooth. Note that in most
cases, dffts%nr[123] is used instead (of course they are the same).
Lots of changes but nothing substantial. Beware unintended side effects
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@7159 c92efa57-630b-4861-b058-cf58834340f0
moved into file Modules/io_files.f90 but not inside module io_files. A better
place is in flib/ in my opinion. Removed dependency of CP upon PW. Lots of
changes but ne substantial or dangerous change.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@6835 c92efa57-630b-4861-b058-cf58834340f0
Paolo Giannozzi