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

[Paolo Giannozzi]

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> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20181115/1afc763c/attachment.html>