[QE-developers] Patch to modify the pw.x behavior at user-provided k-point list

Yunzhe Wang ywang393 at jhu.edu
Tue Dec 4 04:55:23 CET 2018


Dear Professors and Developers of QE,


We did more tests, and found that the increase in number of k-points in IBZ are especially large, for crystals belonging to the Laue class "4/m", "6/m" and "trigonal point group in primitive hexagonal lattice". They are increased by 0.6 ~ 1.0, compared to the grid our server returned, which has already been commensurate with the crystal point group. As you can imagine, the lattice point groups have additional symmetry operations, which expand the sampling k-points.


To better illustrate what happens, I drew a k-point grid our server returned, and the corresponding one after QE expanded, for a crystal with 4/m (C4h) point group we tested. The pictures are projected to x-y plane, since it's easier to see the expansion and the 4-fold symmetry is easier to spot. As you will see in the pictures, the diagonal mirror plane of the tetragonal lattice nearly doubled the kpoints, yet the total energy calculated were very close, below 1^10-5 Ry.


All the pictures are put into a ppt and is in this google drive folder:

https://drive.google.com/drive/folders/1L1zwUTEdNCDsitk7Tx961HmZ7AybVy1U?usp=sharing


As Professor Giannozzi said, it's a bad idea to have additional flags to increase unnecessary complexity. So I added an internal variable, nrot_c, to keep track of the Laue group of the crystal. I also modified a bit the copy_sym() subroutine in "symm_base.f90" to always keep the first nrot_c matrices of s(3,3,48) as the laue group of the crystal. Then in "setup.f90", I let QE only expand the grid by the Laue group.


-     CALL irreducible_BZ (nrot_, s, nsym, time_reversal, ...
+     CALL irreducible_BZ (nrot_c, s, nsym, time_reversal, ...


It's not a big change of the code, only two files are modified slightly. I put "git diff" results in a txt file and included in the google drive above. The modified "setup.f90" and "symm_base.f90" are also put in the folder.


To not disrupt the normal behavior of QE, I tested the flags "noinv", "nosym", "nosym_vec", "use_all_frac", "force_symmorphic" in Monkhorst-Pack k-point scheme, and these flags work as normal.


The tested calculations (two structures, one with inversion and one without) are also in the driver. As you can check, "K_POINTS automatic" works fine, except being expanded only by the centrosymmetric point group of the crystal.


Thanks for your patience in reading this email! Any further advice on how to modify our server to let it be compatible with the QE distribution is appreciated.


Regards,

Yunzhe Wang

Mueller Research Group

Johns Hopkins University



________________________________
From: Yunzhe Wang
Sent: Friday, November 16, 2018 3:24:00 PM
To: developers at lists.quantum-espresso.org
Subject: Re: [QE-developers] Patch to modify the pw.x behavior at user-provided k-point list


Dear Dr. Delugas and Dr. Paulatto,

Thanks for the replies!

We did test the option "nosym = .true.". Theoretically, the calculation will only be performed on an imbalanced set of k-points in BZ, and charge symmetrization will also be completely shut off. The total energy might diverge, if the charge density is optimized to another minimum.

And the real test cases also support the guess, especially in high symmetry case. In primitive FCC Cu, using "nosym = .true." and a set of k-points in IBZ of the symmetry of Fm3m with correct weights, the converged total energy has a difference of ~46 mRy, compared to normal MP converged value. (By "converged", I mean k-point density convergence.) In very low symmetry structure, though, the difference is not such obvious, below ~1 mRy.

Best Regards,
Yunzhe Wang
Mueller Research Group
Johns Hopkins University


________________________________
From: Pietro Delugas <pdelugas at sissa.it>
Sent: Friday, November 16, 2018 3:41:30 AM
To: Yunzhe Wang
Subject: Re: [QE-developers] Patch to modify the pw.x behavior at user-provided k-point list


Dear Yunzhe


if your kpoint are provided as a list, the k-point set has the right symmetry and the proportions between the weight is the right one, maybe you can  try using nosym = .true. and use_all_frac = .true.




On 15/11/18 19:30, Yunzhe Wang wrote:

Dear Professor Giannozzi,


I agree that additional flags will unnecessarily increase the complexity to maintain. My original thought is to not disturb the original behavior of pw.x.


The easier way to stop the expansion by lattice is to change the line 553 of setup.f90 (github) from

                    CALL irreducible_BZ(nrot, s, nsym ...)

to

                    CALL irreducible_BZ(nsym + nsym_na, s, nsym ....)


The original code is to expand by the lattice point group, and the latter is to expand by the crystal point group, with the discarded glide plane / screw axis included. Our server doesn't have the prior knowledge of the FFT grid used in pw.x and therefore returns the k-points in IBZ of the crystal. If pw.x decides to throw away some symmetry, the IBZ should be enlarged to the lower symmetry one, hence with the "+nsym_na" part.


An example would be the one that an actual user reported to us during the beta testing:

The structure is SiC, which she downloaded from ICSD data base. It's hexagonal with 12 atoms in the unit cell, but due to the limited precision that ICSD has (to 10^-4 Angstrom), both pw.x and our server detected it as an orthorhombic structure. Our server returned a mesh with 14 asymmetrical k-points, and QE expanded it, with the point group of a hexagonal lattice, to 84 distinct k-points. The total energies are -394.9476363 Ry and -394.9476383 Ry (a difference of 0.002 mRy) , with the expansion by pw.x shut off and switch on respectively. And the calculation time on 12 processors are 1.55 minutes (14 k-points) and 8.43 minutes (k-points), respectively.


I know in actual serious calculation for publication, the atomic positions would be much precise, and symmetry will be inspected. But a similar case would still be present if a user is working on a slab or a supercell which the crystal symmetry and the unit cell symmetry are very different. An expansion by the lattice point group, will increase the calculation time by a lot. Also, for low symmetry structure, the k-points will increase, averagely, by 1/5 - 1/3, in serveral test cases.


I attached below the input file for the SiC for your reference (the pseudo-potential files are not attached):


&CONTROL
 calculation = 'scf' ,
 pseudo_dir = './' ,
 disk_io = 'none' ,
 verbosity = 'high',
/

&SYSTEM
 ibrav = 0 ,
 ntyp = 2 ,
 nat = 12 ,
 occupations = 'smearing' ,
 smearing = 'marzari-vanderbilt' ,
 degauss = 0.02 ,
 ecutwfc = 50 ,
/

&ELECTRONS
 startingwfc = 'random' ,
/

&IONS
/

&CELL
/

CELL_PARAMETERS bohr
 5.82224621542067 0.00000000000000 0.00000000000000
 -2.91112310771033 5.04221312964210 0.00000000000000
 0.00000000000000 0.00000000000000 28.58172981466878

ATOMIC_SPECIES
 Si 28.0855 Si.GGA-PBE-paw.UPF
 C 12.0107 C.pbe-rrkjus.UPF

ATOMIC_POSITIONS crystal
 Si 1.00000000000000 1.00000000000000 0.50000000000000
 Si 0.00000000000000 0.00000000000000 0.00000000000000
 Si 0.66670000000000 0.33340000000000 0.66640000000000
 Si 0.33330000000000 0.66660000000000 0.16640000000000
 Si 0.33330000000000 0.66660000000000 0.83290000000000
 Si 0.66670000000000 0.33340000000000 0.33290000000000
 C 0.66670000000000 0.33340000000000 0.54120000000000
 C 0.33330000000000 0.66660000000000 0.04120000000000
 C 0.33330000000000 0.66660000000000 0.70800000000000
 C 0.66670000000000 0.33340000000000 0.20800000000000
 C 0.00000000000000 0.00000000000000 0.87460000000000
 C 0.00000000000000 0.00000000000000 0.37460000000000

#  Server version 2018.08.08. ||BETA_MODE|| K-points for C1Si1 with MINDISTANCE=20.0 Angstroms and INCLUDEGAMMA=AUTO FORCEDIAGONAL=false has 112 total points and 14 distinct points. Effective minDistance 21.34579415247883 Angstroms.
K_POINTS crystal
14
0.07142857142857 0.90178571428571 0.25000000000000 8.0
0.21428571428571 0.70535714285714 0.25000000000000 8.0
0.35714285714286 0.50892857142857 0.25000000000000 8.0
0.50000000000000 0.31250000000000 0.25000000000000 8.0
0.64285714285714 0.11607142857143 0.25000000000000 8.0
0.92857142857143 0.72321428571429 0.25000000000000 8.0
0.07142857142857 0.52678571428571 0.25000000000000 8.0
0.21428571428571 0.33035714285714 0.25000000000000 8.0
0.50000000000000 0.93750000000000 0.25000000000000 8.0
0.64285714285714 0.74107142857143 0.25000000000000 8.0
0.07142857142857 0.15178571428571 0.25000000000000 8.0
0.21428571428571 0.95535714285714 0.25000000000000 8.0
0.64285714285714 0.36607142857143 0.25000000000000 8.0
0.21428571428571 0.58035714285714 0.25000000000000 8.0


________________________________
From: Paolo Giannozzi <p.giannozzi at gmail.com><mailto:p.giannozzi at gmail.com>
Sent: Thursday, November 15, 2018 9:04:03 AM
To: General discussion list for Quantum ESPRESSO developers
Cc: Yunzhe Wang
Subject: Re: [QE-developers] Patch to modify the pw.x behavior at user-provided k-point list

Dear Yunzhe

as a rule I am against adding new input variables - there are already hundreds of them - unless there are no alternatives. From what I understand, your procedure produces a list of k-points that are already in the Brillouin Zone reduced using the symmetry of the crystal. If so, the best solution is to ensure that the code does not spoil it when computing the actual k-point grid from the input k-point grid. It would be useful to have a few examples showing what happens.

Paolo

On Wed, Nov 14, 2018 at 8:26 AM Yunzhe Wang <ywang393 at jhu.edu<mailto:ywang393 at jhu.edu>> wrote:

Dear Professors and Developers,


Sorry about the bothering long mail!


Our group has built a server to generate the least-number k-point mesh for a user-given length of the corresponding supercell size. (By "corresponding", I mean a calculation with a dense k-point mesh for a primitive cell, is equivalent to, a calculation with a large supercell with 1 k-point). Currently, the server is able to read the user input file and append the returned K_POINTS card at the end.


However, during the beta testing, we found that QE had the subroutine irreducible_BZ() to force the mesh being expand by the lattice point symmetries first, and then being reduced by the true crystal symmetry. Our server already returns a mesh complying with the crystal symmetry, but will be expanded quite a lot (even more in the low symmetry case) by irreducible_BZ().


So my question is, is there a specific reason to let the mesh being expanded by the lattice symmetry first? Our beta test results show the two cases, expanded and not-expanded (initial K_POINTS card in both cases provided by our server), has nearly the same total energy. And the converged energy by the not-expanded one is also very close to that of the MP generated k-point mesh.


We have wrote a small patch to include an additional flag "kpuser" to switch on and off the expansion, and when it's off, we leave the behavior of QE untouched. Do you think it's ok that we release the patch and let users of our server to patch their local QE distribution? Or we open an issue on QE and let the experts of QE to scrutinize this feature, if you think it's valuable to be incorporated in?


Best Regards,

Yunzhe(Phil) Wang, Graduate Student

Mueller Research Group,

Johns Hopkins University



_______________________________________________
developers mailing list
developers at lists.quantum-espresso.org<mailto:developers at lists.quantum-espresso.org>
https://lists.quantum-espresso.org/mailman/listinfo/developers


--
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222




_______________________________________________
developers mailing list
developers at lists.quantum-espresso.org<mailto:developers at lists.quantum-espresso.org>
https://lists.quantum-espresso.org/mailman/listinfo/developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20181204/911f4120/attachment-0001.html>


More information about the developers mailing list