[Q-e-developers] Plotting many KS orbitals in one pp.x run (and more)

Thu Nov 10 12:02:19 CET 2016

Dear Guido,

thanks for expressing your interest and for your insightful 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.
That sounds like a very reasonable compromise between flexibility and simplicity to me.

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. 
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.

> 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.
> 
I have looked into this now and... it's a bit of a mess.

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.

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).
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.

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.
Yet, it is handled by a different code (stm.f90) which, as far as I can tell, does the following:
If degauss=0, it is identical to LDOS integration.
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.
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.

Best wishes,
Leopold

> 
> 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 on qe-forge.org <http://qe-forge.org/>
>>> 
>>> 
>>> I am sure many of you are familiar with the AiiDA project (http://www.aiida.net/ <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 <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>
> 
> -- 
> 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 <mailto:guido.fratesi at unimi.it>
> web:   https://sites.google.com/site/guidofratesi/ <https://sites.google.com/site/guidofratesi/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20161110/5edf70e9/attachment.html>