
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Dear Paolo,<div class=""><br class=""></div><div class="">thanks a lot for your reply and for having a look at the patch.</div><div class=""><br class=""></div><div class="">I completely agree with your comments regarding the input format. Here is a proposition for the new input format:</div><div class=""><br class=""></div><div class=""><div class="">A) Many KS orbitals</div><div class=""><br class=""></div><div class="">For plot_num 7, pp.x currently has kpoint, kband, spin_component (integers) and lsign (bool).</div><div class="">There is a way of maintaining complete backward compatibility without introducing a new plot_num: We could replace these variables by arrays (of some fixed length that is large enough to cover all reasonable scenarios).</div><div class="">One could then write input files like</div><div class=""><br class=""></div><div class="">kpoint = 1 1 2 2</div><div class="">kband = 23 23 24 24</div><div class="">lsign = .false. .false .false .false.</div><div class="">spin_component = 1 2 1 2</div><div class=""><br class=""></div><div class="">This is the most flexible version. One could also think about keeping lsign and spin_component as single numbers.</div><div class=""><br class=""></div><div class="">Obviously, this approach gets rather verbose for large numbers of KS orbitals. </div><div class="">I see two alternatives, which could be added "on top", if desired (also without breaking backwards compatibility):</div><div class=""> * specifying ranges of indices [kmin,kmax], [kbandmin,kbandmax]</div><div class=""> * specifying an energy range [emin,emax] centered around the Fermi energy</div><div class=""><br class=""></div><div class="">Perhaps implementing both the flexible version and the possibility of specifying an energy range is a good compromise?</div><div class=""><br class=""></div><div class="">B) Local density of states</div><div class=""><br class=""></div><div class="">For the local density of states at the Fermi level (plot_num 3), there currently are no specific parameters.</div><div class="">I.e. we need to introduce at least emin, emax, edelta (or an integer ne), which could be done without breaking backward compatibility</div><div class=""><br class=""></div><div class="">emin = -1.0</div><div class="">emax = +1.0</div><div class="">edelta = 0.1</div></div><div class=""><br class=""></div><div class="">In plot_num 3, the broadening of the electronic levels used to generate the LDOS at Fermi is currently generated using the degauss from the scf calculation.</div><div class="">One might want to add a bit of flexibility by adding a degauss_ldos variable (is there a better name?) that allows to set the broadening by hand.</div><div class=""><br class=""></div><div class="">Best wishes,</div><div class="">Leopold </div><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 08 Nov 2016, at 20:20 , Paolo Giannozzi <<a href="mailto:p.giannozzi@gmail.com" class="">p.giannozzi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">In my opinion, the postprocessing code "pp.x" is a mess beyond control that badly needs to be split, re-organized and cleaned up. This being said: your patch adds a negligible amount of entropy, so I do not personally see major reasons not to accept it. I would however avoid changes to the symmetry section: it is sufficient to call "sym_rho_init" just once, outside the loop over k-points and bands. I would also avoid adding new "plot_num" values since there are no new quantities to be plotted, just new options to plot them<br class=""><br class=""></div>Paolo<br class=""></div><div class="gmail_extra" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""><div class="gmail_quote">On Mon, Nov 7, 2016 at 6:05 PM, Leopold Talirz<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:leopold.talirz@gmail.com" target="_blank" class="">leopold.talirz@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class="">Dear QE developers,</div><div class=""><br class=""></div><div class="">this is a feature request, which I am sending to the mailing list in lieu of access to the QE bug tracker on<span class="Apple-converted-space"> </span><a href="http://qe-forge.org/" target="_blank" class="">qe-forge.org</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I am sure many of you are familiar with the AiiDA project (<a href="http://www.aiida.net/" target="_blank" class="">http://www.aiida.net/</a>), which provides not only a very convenient python infrastructure for running QE calculations, but also a database for a consistent storage of results.</div><div class=""> </div><div class="">We have recently come across a "conflict of philosophy" between QE (more specifically, pp.x) and AiiDA that causes considerable computational/data overhead.</div><div class=""><br class=""></div><div class="">Basically, we need to plot lots of KS orbitals for different nanostructures. </div><div class="">pp.x is designed to produce 1 cube file per execution and AiiDA is designed to produce 1 working directory per calculation. </div><div class="">I.e. when computing 100 KS orbitals from a band structure calculation, using AiiDA the information contained in the band structure directory is replicated 100 times. </div><div class=""> </div><div class="">Our solution so far has been to modify the source of pp.x in such a way that one run can produce N KS orbitals. This has the added benefit of saving a lot of "startup time" as compared to running pp.x N times (in a test run generating 21 KS orbitals, the speedup was ~3x but this does vary, of course).</div><div class="">We have already contacted AiiDA developers Nicolas Mounet and Giovanni Pizzi and they are in favor of this solution as well.</div><div class=""><br class=""></div><div class="">I attach a patch against QE 6.0 (git SHA 93ced686f67fe1f3250824358015e2<wbr class="">ffde364960) that adds plot_num 22 and 23 in pp.x.</div><div class="">plot_num 23 allows to plot N KS orbitals and plot_num 22 allows to plot the local density of states on a grid of energies between emin and emax (useful for scanning tunneling spectroscopy simulations). The patch starts with a commit message that contains sample input files.</div><div class=""><br class=""></div><div class="">I think the main question is, whether you would consider deviating from the "1 run = 1 output file" policy. </div><div class="">If yes, then one can think of the details regarding the implementation (the patch, including the input format for the KS orbitals, can certainly be improved).</div><div class=""><br class=""></div><div class="">Best wishes,</div><div class="">Leopold Talirz, Carlo Pignedoli and Sasha Yakutovich</div><div class=""><br class=""></div><div class=""></div></div><br class=""><div style="word-wrap: break-word;" class=""><div class=""></div></div><br class="">______________________________<wbr class="">_________________<br class="">Q-e-developers mailing list<br class=""><a href="mailto:Q-e-developers@qe-forge.org" class="">Q-e-developers@qe-forge.org</a><br class=""><a href="http://qe-forge.org/mailman/listinfo/q-e-developers" rel="noreferrer" target="_blank" class="">http://qe-forge.org/mailman/<wbr class="">listinfo/q-e-developers</a><br class=""><br class=""></blockquote></div><br class=""><br clear="all" class=""><br class="">--<span class="Apple-converted-space"> </span><br class=""><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,<br class="">Univ. Udine, via delle Scienze 208, 33100 Udine, Italy<br class="">Phone +39-0432-558216, fax +39-0432-558222</div></div></div></div></div></div></div></blockquote></div><br class=""></div></body></html>