Makefiles modified accordingly.
I am not at all happy about this "solution": unneeded dependencies should be
avoided, but this would need to change the way things are deallocated at the
end of a run (clean_pw does too many things at the same time)
file exx_band.f90; make.depend updated accordingly. Module exx now needs
modules exx_base and exx_band. Next: all general variables and routines
moved to exx_base.
k+q grid, symmetry, treatment of limit q => 0, moved to exx_base.f90.
Everything exactly as before, but beware the following changes:
- exx_reinit modified. moved to lr_exx_reinit in TDDFPT/src/lr_exx_kernel.f90
- exx_grid_reinit replaced by modified exx_grid_init and exx_gvec_reinit
three types of calls are possibles : 'Rho', 'Wave', 'tgWave'
In order to enable an fft-type for a given grid the corresponding clock_labels must be set.
One gives a name to desc%rho_clock_lable for 'Rho' type fft and a name to
desc%wave_clock_lable for 'Wave' and 'tgWave' types. Whether tg is
possible depends of the already defined value of desc%have_task_groups variable (mispell to be corrected soon).
definining
dffts%rho_clock_label='ffts', dffts%wave_clock_label='fftw',
dfftp%rho_clock_label='fft', dfftt%rho_clock_label='fftc' and
dfftt%wave_clock_label='fftcw'
and changing
'Dense'->'Rho', 'Smooth'->'Rho', 'Custom'->'Rho', 'CustomWave'->'Wave'
the same clock names and the same overall behavior as with the old interface is obtained.
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
KS_Solvers/CG, KS_Solvers/Davidson, KS_Solvers/Davidson_RCI.
Two are currently used by QE, the third one implements the Davidson
diagonalization within the Reverse Communication Interface paradigm,
courtesy of Micael Oliveira.
KS_Solvers routines depend only on lower level libraries, notably UtilXlib,
LAXlib, (SCA)LAPACK, and BLAS.
reorganization can be improved. For instance some duplicated routines like
cdiaghg and rdiaghg could/should be moved in LAXlib. This could reduce the need
to include KS_Solvers directories in the link step of many codes.
Minimal changes to calling sequence have been made, essentially just adding
h_psi,s_psi,g_psi and h_1psi,s_1psi routines names as arguments (with a
specific calling sequence ihardcode inside the routines that agree with PWSCF one).
This could be avoided adopting the RCI paradigm.
Compiled in serial and parallel, 177/182 pw tests passed (3 that were failing
even before on my laptop pw-berry, pw-langevin, pw-pawatom + 2 unknown==not tested),
12 /17 cp tests passed (some o2-us-para-pbe-X fail but the same was for the
original version)
I assume the modified calling procedure is working and the problem lies somewhere else.
Randomly tested some examples in pw, ph, pwcond and it seams to work.
Please report any problem.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@13644 c92efa57-630b-4861-b058-cf58834340f0
basic operations: error handling, timing clocks, interfaces to basic mpi
calls, find free units...
These routines are moved from Modules and dependencies to other modules
are removed.
MANY files are updated to comply with the move.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@13629 c92efa57-630b-4861-b058-cf58834340f0
US variable qq renamed qq_nt and a new variable qq_na added
because in real space the integral may depend (slightly) on
the atomic position and an atomic value is needed to compute
exactly normalizable wfc.
Whenever realspace tricks are not used qq_nt is used.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@13604 c92efa57-630b-4861-b058-cf58834340f0
Variable "ltetra" moved to common "klist" together with all other variables
setting occupations. All make.depend updated. Should be harmless.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@13204 c92efa57-630b-4861-b058-cf58834340f0
to compute many FFTs at the same time, particularly usefull for EXX
but could be usefule for many linear response code as well
(for the time being implemented only for DFTI and internal FFTW,
should be trivial to extend other drivers)
- more clean-ups
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@12815 c92efa57-630b-4861-b058-cf58834340f0
new subroutine "get_sticks" can be used to initialize and retrieve the sticks for a given input cut-off.
get_sticks can be called in any order (not necessarily starting from the smaller cut-off)
but performance may vary depending on the order.
- NOTE: this is still a transition commit. Further re-factoring to the FFT library is required to
make it more flexible and dynamic, i.e. eliminate pstickset all-in-one FFT setup routine.
Once the re-factoring will be over, the initialization of a single FFT object will feature:
a) call subroutine to set basic grid informations and allocation
fft_type_allocate
b) call subroutine to define if the FFT is going to be performed in parallel or serial (even in parallel run)
temporarily represented by the new get_sticks subroutine
c) call subroutine to "activate" the fft_types object
temporarily represented by fft_type_set
FFT objects may then be created (almost) freely and (almost) independently from the other FFT objects,
behind the scene, we need to keep coherence between sticks map and sticks owner, in order to avoid grid data remapping
(this may change in future, for specific needs).
In other words the above sequence could be called to initialize a new fft descriptor anywhere at any time,
but a coherence will be kept with previous initializations. A keyword (not yet implemented) could be
used to unbound the new descriptors from the old one, then you need to know what you are doing...
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@12721 c92efa57-630b-4861-b058-cf58834340f0
the global list of k-points, used for k-points parallelization, moved to a
single subroutine. Most of those pieces of code were never actually used
(k-point parallelization is not implemented in several of the utilities)
but just blindly copied from the code performing I/O of wavefunctions.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@12720 c92efa57-630b-4861-b058-cf58834340f0
(it was acting only on descriptor variables, noneed to keep it into module)
- name change: all function/variables named *_dlay_* renamed *_type_* for consistency
- IMPORTANT: fft_type_allocate merged with real space grid initializaiton
some other grid functions removed/merged with fft types.
Since some initialization has been moved elseware there could be some SIDE EFFECT
- In practice, now grid dimensions (nr1, nr2, nr3) comes with fft variable definition
and variable allocation.
NEXT: review of the initialization/setting of the fft parallelization
- real space grid initialization subroutines moved to fft_types module
(it was acting only on descriptor variables, no need to keep it in Modules)
- name change: all function/variables named *_dlay_* renamed *_type_* for consistency
- IMPORTANT: fft_type_allocate merged with real space grid initializaiton
some other grid functions removed/merged with fft types.
Since some initialization has been moved elseware there could be some SIDE EFFECT
- In practice, now grid dimensions (nr1, nr2, nr3) comes with fft variable definition
and variable allocation.
NEXT: review of the initialization/setting of the fft parallelization
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@12703 c92efa57-630b-4861-b058-cf58834340f0
set prior to calls fft_dlay_allocate, fft_dlay_set, fft_dlay_scalar.
in these subsequent calls grid dimensions are removed from input and taken from the grid descriptor
that is provided anyway.
-stick_set.f90 and fft_custom.f90 modified accordingly.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@12572 c92efa57-630b-4861-b058-cf58834340f0
good idea to call "h_psi" a routine that does something related to but
different from H\psi. Corrected a few grossly wrong comments.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@12440 c92efa57-630b-4861-b058-cf58834340f0
prevent trouble with OS-X. May or may not work (it won't unless configure
is updated: please somebody with v.2.63 of autoconf do it), may turn out to
be obsolete anyway.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@12364 c92efa57-630b-4861-b058-cf58834340f0
moment to get rid of flib/, whose usefulness is far from obvious. The content
of flib/ is now in Modules/. Many makefiles updated and little more.
Packages using QE routines should just remove links to flib/flib.a.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@12072 c92efa57-630b-4861-b058-cf58834340f0
PH/phcom.f90 split in PH/phcom.f90 + LR_Modules/lrcom.f90 that contains
qpoint module
A number of routines using these variables needed to be modified to explicitely
load qpoint (in addition to phcom)
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@12005 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
Script generating make.depend temporarily modified so that it doesn't produce
invalid make.depend files due to references to (missing unless installed)
environ modules
Version number updated to 5.0.99 (got the message?)
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@10844 c92efa57-630b-4861-b058-cf58834340f0
change with PHonon phq_init.f90. I also added a new module wannier_gw, for a tight integration with the rest of the QE.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@10772 c92efa57-630b-4861-b058-cf58834340f0
Note: I'll be working to clean GWL a little bit in the following weeks, to see if implementing some tasks I've been asked are feasible or not. Please forward me any other
tests for this code, so that I can implement a daily test
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@10769 c92efa57-630b-4861-b058-cf58834340f0
(I think): mp_bands.f90 . Many changes but nothing dangerous. Note that
codes not in svn may be broken by this change, but the fix is very simple
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@10567 c92efa57-630b-4861-b058-cf58834340f0
variables for the "world" MPI communicator. The latter are to be found in
world_comm instead. mp_global should be used only to start and to end the
various parallelization levels. Many small but harmless changes: a few
variables removed or moved to another module in most cases.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@10558 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
paoloumari