to initialize G-vectors for all grids: one (ggen) to generate a new set of
G-vectors, one (ggens) to generate a subset of G-vectors with the same
ordering as in the original set.
two subroutines: "ggen" takes care of G-vectors for the FFT grid only,
"ggens" takes care of the subgrid only, with exactly the same ordering.
Seems to work, please verify
in the "custom" FFTs that are used in the calculation of V_x\psi). Cleanup:
information on whether 3D FFTs are to be used is contained in variable
dfft*%lpara, set in initialization. In my opinion we could set lpara=.false.
always if the FFT is done on a single processor, get rid of __USE_3D_FFT.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@13706 c92efa57-630b-4861-b058-cf58834340f0
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
- add optional parameters to make ggen working with both local and global sorting.
In particular:
if no_global_sort is present (and it is true) G vectors are sorted only locally and not globally.
In this case no global array should be allocated and sorted (saving memory
and a lot of computational time for large systems).
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@9302 c92efa57-630b-4861-b058-cf58834340f0
using mamory saving features (for low memory machines).
Sometime low memory stuff conflicts with other features,
like wf_collect and, for the time being, I prefer
to exclude them at compile time.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@8312 c92efa57-630b-4861-b058-cf58834340f0
calculate the number of G-vectors and the dimension of G-vector arrays.
This should prevent mysterious errors in vc-relax. Harmless if the grid
dimensions are sufficiently large to accommodate all G-vectors; not sure
if they are not...beware unintended side effects
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@7629 c92efa57-630b-4861-b058-cf58834340f0
- Grid dimensions for both dense and smooth grids are in Modules/griddim.f90
- Variables describing G vectors and their mapping onto FFT grids (both
dense and smooth) are in Modules/recvec.f90
- FFT descriptors are defined in Modules/fft_types.f90
- Variables describing G-vector distribution across processors are
contained in Modules/stick_base.f90
- Distribution across processors of G vectors in sticks and planes
is performed in Modules/stick_set.f90, routine pstickset, which
also initializes FFT descriptors
- G vectors and their mapping onto FFT grids are calculated in
Modules/recvec_subs.f90 (routine ggen: a modified version of PW one,
replacing the CP one ggencp)
Testing is very limited but given the kind of modifications there should
be no major problem, I hope.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@7384 c92efa57-630b-4861-b058-cf58834340f0
fabrizio22