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

Fri Nov 16 21:24:00 CET 2018

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/20181116/00c808ee/attachment-0001.html>