<div dir="ltr"><div>My standard answer to git-related questions is invariably "I don't know (and don't want to know)"</div><div><br></div><div>Paolo<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 9, 2020 at 7:56 AM Phil Wang <<a href="mailto:ywang393@jhu.edu">ywang393@jhu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Prof. Giannozzi,<br>
<br>
Sorry about the late reply! I was put together some slides for a conference and got trapped there.<br>
<br>
I rebased my fork branch to the latest develop branch and this might have caused gitlab to fail in identifying commits. I’m trying to figure out a way. Should I start a new pull request?<br>
<br>
Best,<br>
Phil<br>
<br>
From: Paolo Giannozzi <<a href="mailto:p.giannozzi@gmail.com" target="_blank">p.giannozzi@gmail.com</a>><br>
Sent: Tuesday, August 4, 2020 7:36 AM<br>
To: General discussion list for Quantum ESPRESSO developers <<a href="mailto:developers@lists.quantum-espresso.org" target="_blank">developers@lists.quantum-espresso.org</a>>; Phil Wang <<a href="mailto:ywang393@jhu.edu" target="_blank">ywang393@jhu.edu</a>><br>
Subject: Re: [QE-developers] Routines for creation of a new type k-point grid: Generalized Monkhorst-Pack Grid<br>
<br>
<br>
External Email - Use Caution<br>
<br>
<br>
<br>
<br>
Hi<br>
<br>
the xml file has a card containing all the info needed to re-generate the k-point grid, so it shouldn't be a big problem to extend it. For some obscure reason gitlab does not show the diffs for the merge request you mention: what are the three new flags?<br>
<br>
Paolo<br>
<br>
On Mon, Aug 3, 2020 at 7:09 PM Phil Wang <<a href="mailto:ywang393@jhu.edu" target="_blank">ywang393@jhu.edu</a><mailto:<a href="mailto:ywang393@jhu.edu" target="_blank">ywang393@jhu.edu</a>>> wrote:<br>
Dear QE Developers,<br>
<br>
We are implementing a new type of k-point grid in QE, and called it Generalized Monkhorst-Pack K-Point Grid (GMP grids) (theory: <a href="https://journals.aps.org/prb/abstract/10.1103/PhysRevB.93.155109" rel="noreferrer" target="_blank">https://journals.aps.org/prb/abstract/10.1103/PhysRevB.93.155109</a><<a href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjournals.aps.org%2Fprb%2Fabstract%2F10.1103%2FPhysRevB.93.155109&data=02%7C01%7Cywang393%40jhu.edu%7C1879ad379fa243aa023208d8386aa3a0%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C637321377943155361&sdata=1aaOFghNK%2FblMRAlJ41jF4owHAWCgeUikyDQ8Zk0qXM%3D&reserved=0" rel="noreferrer" target="_blank">https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjournals.aps.org%2Fprb%2Fabstract%2F10.1103%2FPhysRevB.93.155109&data=02%7C01%7Cywang393%40jhu.edu%7C1879ad379fa243aa023208d8386aa3a0%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C637321377943155361&sdata=1aaOFghNK%2FblMRAlJ41jF4owHAWCgeUikyDQ8Zk0qXM%3D&reserved=0</a>>). We added new routines separately from the original uniform grid generation procedures (algorithms: <a href="https://arxiv.org/abs/1907.13610" rel="noreferrer" target="_blank">https://arxiv.org/abs/1907.13610</a><<a href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F1907.13610&data=02%7C01%7Cywang393%40jhu.edu%7C1879ad379fa243aa023208d8386aa3a0%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C637321377943165352&sdata=1kOyc1MB7n777Gx%2BqJUj2%2B%2Blxz%2FG8yPuDgpY3oTg5sg%3D&reserved=0" rel="noreferrer" target="_blank">https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F1907.13610&data=02%7C01%7Cywang393%40jhu.edu%7C1879ad379fa243aa023208d8386aa3a0%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C637321377943165352&sdata=1kOyc1MB7n777Gx%2BqJUj2%2B%2Blxz%2FG8yPuDgpY3oTg5sg%3D&reserved=0</a>>), to minimize any interference with existing and well-tested routines.<br>
<br>
The only changes to the original code are on k-point expansion part of setup() and copy_sym(). A detailed explanation of its effect on normal pw.x scf calculations can be found in “Merge Request !292”. It basically reduced the number of distinct k-points found in a grid by forcing the k-point grid to comply with Laue class of crystallographic point group, instead of full lattice point group. We found it could reduce the computational time, while keeping the accuracy of energy calculation. The conflictions with phonon code reminded by Prof. Giannozzi are fixed with new patches.<br>
<br>
This email is meant to ask are there any concerns for adding new flags to the .xml logging of calculations. There are three new flags for generating GMP grids. The proposed change on logging is recording these three new flags when GMP is used, instead of “nk1”, “nk2”, “nk3”. I don’t want to broke any routines and existing workflows (like AiiDA archiving). If there are potential conflictions with such IO change, or better ways for adding them, or standard procedures I should flow when implementing these changes, I’m all ears and would very much appreciate them!<br>
<br>
<br>
Best Regards,<br>
Yunzhe (Phil) Wang<br>
Mueller Research Group<br>
Department of Materials Science and Engineering<br>
Johns Hopkins University<br>
<br>
_______________________________________________<br>
developers mailing list<br>
<a href="mailto:developers@lists.quantum-espresso.org" target="_blank">developers@lists.quantum-espresso.org</a><mailto:<a href="mailto:developers@lists.quantum-espresso.org" target="_blank">developers@lists.quantum-espresso.org</a>><br>
<a href="https://lists.quantum-espresso.org/mailman/listinfo/developers" rel="noreferrer" target="_blank">https://lists.quantum-espresso.org/mailman/listinfo/developers</a><<a href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.quantum-espresso.org%2Fmailman%2Flistinfo%2Fdevelopers&data=02%7C01%7Cywang393%40jhu.edu%7C1879ad379fa243aa023208d8386aa3a0%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C637321377943165352&sdata=Nl0cOcyz9L16J8%2FWa9rEMQbYRmLffjR9HQkqBn6h3dg%3D&reserved=0" rel="noreferrer" target="_blank">https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.quantum-espresso.org%2Fmailman%2Flistinfo%2Fdevelopers&data=02%7C01%7Cywang393%40jhu.edu%7C1879ad379fa243aa023208d8386aa3a0%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C637321377943165352&sdata=Nl0cOcyz9L16J8%2FWa9rEMQbYRmLffjR9HQkqBn6h3dg%3D&reserved=0</a>><br>
<br>
<br>
--<br>
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,<br>
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy<br>
Phone +39-0432-558216, fax +39-0432-558222<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,<br>Univ. Udine, via delle Scienze 208, 33100 Udine, Italy<br>Phone +39-0432-558216, fax +39-0432-558222<br><br></div></div></div></div></div>