<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Dear Guido,<div class=""><br class=""></div><div class="">thanks for expressing your interest and for your insightful suggestions.</div><div class=""><div><br class=""><blockquote type="cite" class=""><div bgcolor="#FFFFFF" text="#000000" class="">As for the input specifications for multiple orbitals, I may
guess that specifying the ranges for kpoint, kband, and also
spin_component, would be an easy way for a less specialized user
(presumably lsign can be taken constant). I would opt for
replacing these three input variables by
array(1)=minval,array(2)=maxval. If maxval is not specified, the
standard operation is performed.</div></blockquote><div>That sounds like a very reasonable compromise between flexibility and simplicity to me.</div><div><br class=""></div><div>What about adding, in addition, the possibility to specify an energy range [emin, emax] around Fermi? pp.x would produce an error, if emin/emax are set together with any of the other conflicting options. </div><div>In quite a few use cases, this might save users the step of searching for the relevant band indices in the QE output. But anyhow, this is something that could easily be added later on.</div><br class=""><blockquote type="cite" class=""><div bgcolor="#FFFFFF" text="#000000" class=""><p class="">As for the LDOS, a similar option is present as plotnum=10, where
you can specify emin-emax. Perhaps a generalization of this one,
rather that plotnum=3, would be more appropriate? Notice that
broadenings may be defined differently in the various related
schemes provided by plotnum=3,5,10.</p></div></blockquote><div>I have looked into this now and... it's a bit of a mess.</div><div><br class=""></div><div>Producing an LDOS for one particular energy (plot_num 3 only does the Fermi energy) only makes sense with broadening of the energy levels. This also applies to the functionality we want to add (LDOS over a grid of energies) and I believe this is why our functionality should be merged into plot_num 3.</div><div><br class=""></div><div>Producing an integrated LDOS between emin and emax (plot_num 10) does make sense both without broadening (in this case you simply sum the energy levels that fall within the window) and with broadening (in this case, you need to integrate the broadening function within the energy window for all energy levels).</div><div>Currently, plot_num 10 does not apply broadening, which is what I would expect as default behavior. I am not sure whether adding the possibility of broadening for these integrated quantities is desired.</div><div><br class=""></div><div>You might expect that producing an STM image in the Tersoff-Hamann approximation (plot_num 5) simply involves integrating the LDOS between the Fermi energy and another energy and should therefore be identical to plot_num 10.</div><div>Yet, it is handled by a different code (stm.f90) which, as far as I can tell, does the following:</div><div>If degauss=0, it is identical to LDOS integration.</div><div>For finite degauss, it does the usual LDOS integration *plus* some contribution of states within 3*degauss of the integrated energy window, weighted by the energetic distance from the integration limits (stm.f90, line 129). While it might seem a bit unphysical to apply broadening only to the levels outside the window, I guess the philosophy behind it is one of partial occupation of energy levels rather than energetic broadening of energy levels themselves.</div><div>In my opinion, it could make sense to let stm.f90 use the ldos integration functionality. Note, however, that producing STM images may involve more than LDOS integration. I have been wanting to add Chen's derivative rules for some time to be able to produce STM images for other than s-wave tips. So, I am not sure whether merging STM and LDOS integration in the *input* is necessarily the best way to go.</div><div><br class=""></div><div>Best wishes,</div><div>Leopold</div><div><br class=""></div><blockquote type="cite" class=""><div bgcolor="#FFFFFF" text="#000000" class=""><br class="">
<div class="moz-cite-prefix">On 09/11/2016 18:52, Leopold Talirz
wrote:<br class="">
</div>
<blockquote cite="mid:D751FF6F-12C7-4254-9D78-E2FF248DD052@gmail.com" type="cite" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" 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 class="">
<blockquote type="cite" class="">
<div class="">On 08 Nov 2016, at 20:20 , Paolo Giannozzi
<<a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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>
<br class="">
<br class="">
______________________________<wbr class="">_________________<br class="">
Q-e-developers mailing list<br class="">
<a moz-do-not-send="true" href="mailto:Q-e-developers@qe-forge.org" class="">Q-e-developers@qe-forge.org</a><br class="">
<a moz-do-not-send="true" 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 class="" clear="all">
<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>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
Q-e-developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Q-e-developers@qe-forge.org">Q-e-developers@qe-forge.org</a>
<a class="moz-txt-link-freetext" href="http://qe-forge.org/mailman/listinfo/q-e-developers">http://qe-forge.org/mailman/listinfo/q-e-developers</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="72">--
Guido Fratesi
Dipartimento di Fisica
Universita` degli Studi di Milano
Via Celoria 16, 20133 Milano, Italy
Phone: +39 02 503 17348
email: <a class="moz-txt-link-abbreviated" href="mailto:guido.fratesi@unimi.it">guido.fratesi@unimi.it</a>
web: <a class="moz-txt-link-freetext" href="https://sites.google.com/site/guidofratesi/">https://sites.google.com/site/guidofratesi/</a>
</pre>
</div>
</blockquote></div><br class=""></div></body></html>