[Q-e-developers] Plotting many KS orbitals in one pp.x run (and more)
Guido Fratesi
guido.fratesi at unimi.it
Thu Nov 10 10:38:05 CET 2016
Dear Leopold,
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//velopment and let me add a couple of
suggestions.
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.
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.
Best wishes,
Guido
On 09/11/2016 18:52, Leopold Talirz wrote:
> Dear Paolo,
>
> thanks a lot for your reply and for having a look at the patch.
>
> I completely agree with your comments regarding the input format. Here
> is a proposition for the new input format:
>
> A) Many KS orbitals
>
> For plot_num 7, pp.x currently has kpoint, kband, spin_component
> (integers) and lsign (bool).
> 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).
> One could then write input files like
>
> kpoint = 1 1 2 2
> kband = 23 23 24 24
> lsign = .false. .false .false .false.
> spin_component = 1 2 1 2
>
> This is the most flexible version. One could also think about keeping
> lsign and spin_component as single numbers.
>
> Obviously, this approach gets rather verbose for large numbers of KS
> orbitals.
> I see two alternatives, which could be added "on top", if desired
> (also without breaking backwards compatibility):
> * specifying ranges of indices [kmin,kmax], [kbandmin,kbandmax]
> * specifying an energy range [emin,emax] centered around the Fermi energy
>
> Perhaps implementing both the flexible version and the possibility of
> specifying an energy range is a good compromise?
>
> B) Local density of states
>
> For the local density of states at the Fermi level (plot_num 3), there
> currently are no specific parameters.
> I.e. we need to introduce at least emin, emax, edelta (or an integer
> ne), which could be done without breaking backward compatibility
>
> emin = -1.0
> emax = +1.0
> edelta = 0.1
>
> 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.
> 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.
>
> Best wishes,
> Leopold
>
>
>
>
>> On 08 Nov 2016, at 20:20 , Paolo Giannozzi <p.giannozzi at gmail.com
>> <mailto:p.giannozzi at gmail.com>> wrote:
>>
>> 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
>>
>> Paolo
>>
>> On Mon, Nov 7, 2016 at 6:05 PM, Leopold
>> Talirz<leopold.talirz at gmail.com <mailto:leopold.talirz at gmail.com>>wrote:
>>
>> Dear QE developers,
>>
>> this is a feature request, which I am sending to the mailing list
>> in lieu of access to the QE bug tracker onqe-forge.org
>> <http://qe-forge.org/>
>>
>>
>> I am sure many of you are familiar with the AiiDA project
>> (http://www.aiida.net/), which provides not only a very
>> convenient python infrastructure for running QE calculations, but
>> also a database for a consistent storage of results.
>> We have recently come across a "conflict of philosophy" between
>> QE (more specifically, pp.x) and AiiDA that causes considerable
>> computational/data overhead.
>>
>> Basically, we need to plot lots of KS orbitals for different
>> nanostructures.
>> pp.x is designed to produce 1 cube file per execution and AiiDA
>> is designed to produce 1 working directory per calculation.
>> 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.
>> 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).
>> We have already contacted AiiDA developers Nicolas Mounet and
>> Giovanni Pizzi and they are in favor of this solution as well.
>>
>> I attach a patch against QE 6.0 (git SHA
>> 93ced686f67fe1f3250824358015e2ffde364960) that adds plot_num 22
>> and 23 in pp.x.
>> 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.
>>
>> I think the main question is, whether you would consider
>> deviating from the "1 run = 1 output file" policy.
>> 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).
>>
>> Best wishes,
>> Leopold Talirz, Carlo Pignedoli and Sasha Yakutovich
>>
>>
>>
>> _______________________________________________
>> Q-e-developers mailing list
>> Q-e-developers at qe-forge.org <mailto:Q-e-developers at qe-forge.org>
>> http://qe-forge.org/mailman/listinfo/q-e-developers
>> <http://qe-forge.org/mailman/listinfo/q-e-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
>
>
>
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org
> http://qe-forge.org/mailman/listinfo/q-e-developers
--
Guido Fratesi
Dipartimento di Fisica
Universita` degli Studi di Milano
Via Celoria 16, 20133 Milano, Italy
Phone: +39 02 503 17348
email: guido.fratesi at unimi.it
web: https://sites.google.com/site/guidofratesi/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20161110/4681c86e/attachment.html>
More information about the developers
mailing list