mirror of https://gitlab.com/QEF/q-e.git
![]() 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 |
||
---|---|---|
.. | ||
reference | ||
README | ||
run_example |
README
To have 'better' projector in LDA+U calculations some localized Wannier functions of the relevant bands around the Fermi energy can be used. See for instance N.Marzari and D.Vanderbilt, PRB 56, 12847 (1997) and I. Sousa, N. Marzari, and D.Vanderbilt, PRB 65, 035109 (2001) for the definition and construction of Maximally Localized Wannier Functions (MLWF). Although it is possible to generate MLWF with the software distributed by Nicola Marzari at www.wannier.org, here we follow a simpler prescription and fix the phase-factor freedom---intrinsic in any Wannier function determination---in a sub-optimal but simple way using the atomic wavefunction as a guide. This is done as a post-processing step with a poormanwannier tool (pmw.x) that reads atomic wavefunctions and band structure of an LDA calculation and replaces the atomic wavefunctions with our simple Wannier functions. The subsequent LDA+U calculation is performed specifying in the system namelist U_projection_type='file' so that the freshly produced Wannier functions are used in the projection. The outcome of this calculation is an insulating state with d-level occupations really close to 0 or 1. In addition to this, the example shows how to obtain fat bands (i.e., band structures "weighted" by the overlap with atomic wave functions) and thereby identify which bands have the largest content of, e.g., Fe 3d-character. A non-self consistent calculation is used to compute the band structure along a path in the Brillouin zone, followed by the calculation of the projections onto atomic orbitals (projwfc.x) and the band symmetry analysis (bands.x). The small utility plotband.x combines those data and produces band structure plots with an additional third column containing the weight on the selected wavefunction (or the sum, if more than one is specified). In this case, the projections onto the 10 atomic 3d wavefunctions of the two Fe are summed up.