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

Fri Jan 6 23:11:59 CET 2017

Dear Paolo,

thanks for moving forward so quickly with the patch.
I have now verified that the specific namelist behavior required for the patch is provided by the recent gfortran, ifort, pgf90 and nag compilers (although I have compiled full QE only with gfortran and ifort).

While testing the examples provided with PP I stumbled upon a problem in my patch (namely, when pp.x is used with an empty INPUTPP section). The attached patch resolves the problem and also includes some fixes to the documentation (which I have finally been able to compile).

While running the examples, I noticed two further things that are not related to PP:

* example05:  run_example (line 190) wants to copy a file feo_af.occup that doesn't seem to be produced by pw.x. Perhaps this output was removed at some point?
* example06:  run_example (line 177) stops with
  running the band calculation for Fe with PAW and spin-orbit...[cli_0]: aborting job:
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0

Apart from this, the examples run through fine.

Best,
Leopold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugfix.patch
Type: application/octet-stream
Size: 11302 bytes
Desc: not available
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20170106/01e02630/attachment.obj>
-------------- next part --------------

> On 11 Nov 2016, at 13:10 , Nicola Marzari <nicola.marzari at epfl.ch> wrote:
> 
> 
> 
> Dear All,
> 
> 
> slightly tangential to this discussion, but just wanted to remind/alert everyone
> that Giovanni Pizzi (and especially his Japanese colleagues) have made a major
> effort in devising standard paths in k-space for any structure, in ways that are
> fully compliant with current crystallography standards (this was not the case
> up to now).
> 
> Great if we all could adhere to this framework - see page below for a link to
> the paper, an online tool that provides all points, labels and paths given a
> pwscf input, and the link to the github repository if you want to use directly
> the python source:
> 
> http://www.materialscloud.org/tools/seekpath/input_structure/
> 
> 
> 				nicola
> 
> 
> 
> On 11/11/2016 12:41, Pignedoli, Carlo wrote:
>> Dear all,
>> I understand it could be more complex, but since
>> you are going to consider this useful modification
>> I would spend an effort in trying to allow flexibility in the selection of k-points:
>> 
>> normally I will plot k-points after a bandstructure calculation
>> performed with several k-points (could easily be 100 in one directions)
>> 
>> I iwl probably need to plot soem selected bands at selected k-points
>> 
>> now a "stride option" like plot every 3 kpoint would not be enough
>> because most likely it would exclude some high simmetry points...
>> 
>> thus a format that allows to specify
>> 
>> 1 5 10 15 20 25 34
>> in a calculation where e.g. 1 is G and 34 is X
>> would be extremely useful.
>> 
>> Kind regards
>> 
>> Carlo
>> 
>> 
>> 
>> 
>> Dr. Carlo Antonio Pignedoli
>> Empa
>> Swiss Federal Laboratories for Materials Science and Technology
>> Überlandstrasse 129
>> 8600 Dübendorf
>> Switzerland
>> Tel +41 58 765 4206
>> Fax +41 58 765 4031
>> e-mail carlo.pignedoli at empa.ch
>> www.surfaces.ch
>> 
>> 
>>> -----Original Message-----
>>> From: Leopold Talirz [mailto:leopold.talirz at gmail.com]
>>> Sent: Thursday, November 10, 2016 12:55
>>> To: tone.kokalj at ijs.si
>>> Cc: General discussion list for Quantum ESPRESSO developers; Yakutovich,
>>> Aliaksandr; Pignedoli, Carlo
>>> Subject: Re: [Q-e-developers] Plotting many KS orbitals in one pp.x run (and
>>> more)
>>> 
>>> Dear Tone,
>>> 
>>> I agree that Guido's suggestion is the best compromise.
>>> 
>>> Regarding your example, I think one should keep requiring the user to use
>>> the kpoint keyword as well (otherwise one might end up by lots of orbitals by
>>> accident).
>>> But I guess this was not the point you were making. Regarding input format,
>>> the same code will allow both
>>> 
>>> kband(1) = 21
>>> kband(2) = 38
>>> spin_component(1) = 0
>>> spin_component(2) = 3
>>> 
>>> and
>>> 
>>> kband = 21 38
>>> spin_component = 0 3
>>> 
>>> and
>>> 
>>> kband = 21
>>> spin_component = 0
>>> 
>>> (at least with gfortran and intel, I haven't tested other compilers so far).
>>> 
>>> Best wishes,
>>> Leopold
>>> 
>>> 
>>>> On 10 Nov 2016, at 11:38 , Tone Kokalj <tone.kokalj at ijs.si> wrote:
>>>> 
>>>> On Thu, 2016-11-10 at 11:20 +0000, Leopold Talirz wrote:
>>>>> Dear Tone,
>>>>> 
>>>>>> In addition to lsign, I suggest also to make the spin_component
>>>>>> constant: if more components are needed it can be done with few pp.x
>>>>>> calculations.
>>>>> 
>>>>> From just the input file perspective I don't see a particular reason
>>>>> to handle spin_component differently than kpoint and kband. Or am I
>>>>> missing something?
>>>> 
>>>> Indeed you are right; if somebody is interested in more components it
>>>> would make sense to make the spin_component follow the Guido
>>>> suggestion. To illustrate: I found this useful (Guido scheme)
>>>> 
>>>> kband(1) = 21
>>>> kband(2) = 38
>>>> spin_component(1) = 0
>>>> spin_component(2) = 3
>>>> 
>>>> according to Guide scheme this should make the total and x,y,z
>>>> components for bands from 21 to 38. But I found this too fine grained:
>>>> 
>>>> kband = 21 22 23 24
>>>> spin_component = 1 1 2 1
>>>> 
>>>> 
>>>> Best regards, Tone
>>>> --
>>>> J. Stefan Institute, Jamova 39, 1000 Ljubljana, Slovenia
>>>> (tel: +386-1-477-3523 // fax: +386-1-251-9385)
>> 
>> 
>> _______________________________________________
>> Q-e-developers mailing list
>> Q-e-developers at qe-forge.org
>> http://qe-forge.org/mailman/listinfo/q-e-developers
>> 
> 
> -- 
> ----------------------------------------------------------------------
> Prof Nicola Marzari, Chair of Theory and Simulation of Materials, EPFL
> Director, National Centre for Competence in Research NCCR MARVEL, EPFL
> http://theossrv1.epfl.ch/Main/Contact http://nccr-marvel.ch/en/project