<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Dear Leopold,</p>
<p>I'm also frequently using pp.x for plotting multiple
wavefunctions and generally resorted to bash scripts to run pp.x
repeatedly. As such I would be interested in this de<i></i>velopment
and let me add a couple of suggestions.</p>
<p>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.</p>
<p>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>
<p>Best wishes,<br>
</p>
<p>Guido<br>
</p>
<br>
<div class="moz-cite-prefix">On 09/11/2016 18:52, Leopold Talirz
wrote:<br>
</div>
<blockquote
cite="mid:D751FF6F-12C7-4254-9D78-E2FF248DD052@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
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 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>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
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>
<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>
</body>
</html>