[QE-developers] Patch to modify the pw.x behavior at user-provided k-point list
Pietro Delugas
pdelugas at sissa.it
Fri Nov 16 09:59:54 CET 2018
Dear Yunzhe
if your kpoint are provided as a list, the k-point set has the right
symmetry and the proportions between the weights 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>
> *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
> 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/e45f114b/attachment-0001.html>
More information about the developers
mailing list