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

[Leopold Talirz]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20161109/298fd037/attachment.html>