[Q-e-developers] on the calculation of Hubbard U values

Fri Oct 13 13:26:27 CEST 2017

If somebody provides such a list of elements, it can still be added to
v.6.2, but I am not going to spend more than 5' on this.

Paolo

On Fri, Oct 13, 2017 at 10:53 AM, José Carlos Conesa <jcconesa at icp.csic.es>
wrote:

> Dear all,
>
> I fully understand Timrov's concern about the available pseudopotentials,
> I was not aware of that problem. What I would suggest then, if a well
> tested qe 6.2 version is to be released very soon, is to include in those
> .f90 files just all elements for which no problem exists, and leave for a
> later version a better handling of this issue.
>
> All the best,
>
> El 13/10/2017 a las 10:44, Timrov Iurii escribió:
>
> Dear All,
>
>
> There were some discussions outside of the QE developers mailing list
> about this issue, and we would like to share with you our thoughts. José
> proposed his changes to the files set_hubbard_l.f90, set_hubbard_n.f90,
> tabd.f90, where all elements (we haven't checked that really all) are
> tabulated with the corresponding channel to be effected by the Hubbard
> correction. We think we should not hurry and not include this in QE
> 6.2 which is going to be released very soon (as far as we know).
>
>
> The main problem is that some pseudos may not comply with the default
> choice of states made in the aforementioned routines. For example, for La,
> in José's version of set_hubbard_l.f90, it is specified that hubbard_l = 3
> (i.e. the f state). While some pseudos include empty 4f states (e.g.
> Pslibrary, GBRV), some pseudos do not (e.g. Dojo library,
> La.pbe-nsp-van.UPF from the QE web site). So, in the latter case the code
> will crash because the f channel is not present in the pseudo. Thus, we
> have to be careful. As Paolo and we discussed, it
>  is probably better to have a possibility to specify hubbard_l from the
> input (e.g. if you choose the pseudo which contains 4f for La and you want
> to apply a Hubbard correction to 4f, and not 5d, then just specify
> hubbard_l = 3 from the input; if nothing is specified in the input, the
> code can use the default value which should work for all pseudos, e.g.
> hubbard_l =2 for La). Another option might be to keep as the default
> hubbard_l  = 3 for La, and if the code does not find the f state in the
> pseudo then stop smoothly and ask the user to change hubbard_l by
> specifying it in the input. As we said, probably it would be safer to
> implement this things after the release of QE 6.2 in order to avoid
> possible bugs.
>
>
> Best regards,
>
> Iurii and Matteo
>
> Swiss Federal Institute of Technology Lausanne (EPFL)
> Laboratory of Theory and Simulation of Materials (THEOS)
> CH-1015 Lausanne, Switzerland
> +41 21 69 34 881
>
> ------------------------------
> *From:* q-e-developers-bounces at qe-forge.org <q-e-developers-bounces at qe-
> forge.org> <q-e-developers-bounces at qe-forge.org> on behalf of Paolo
> Giannozzi <p.giannozzi at gmail.com> <p.giannozzi at gmail.com>
> *Sent:* Thursday, October 12, 2017 7:20 PM
> *To:* General discussion list for Quantum ESPRESSO developers
> *Cc:* jcconesa at icp.csic.es
> *Subject:* Re: [Q-e-developers] on the calculation of Hubbard U values
>
> I also think that a better solution would be providing parameters of
> Hubbard U from input. Something like a "Hubbard_U" card with
> Mn(3d)=4.0
> O(2p)=5.0
> ...
>
> Paolo
>
> On Thu, Oct 12, 2017 at 1:50 PM, Timrov Iurii <iurii.timrov at epfl.ch>
> wrote:
>
>> Dear Jose,
>>
>>
>> Thanks for the remark, we will keep this in mind when working on the
>> porting of the DFpT code to compute U to the official release of QE.
>> Perhaps it would be useful to introduce input variables which allow user
>> to specify which atomic manifold to associate with the Hubbard correction.
>>
>>
>> Best regards,
>>
>> Iurii
>>
>>
>> --
>> Dr. Iurii Timrov
>> Postdoctoral Researcher
>> Swiss Federal Institute of Technology Lausanne (EPFL)
>> Laboratory of Theory and Simulation of Materials (THEOS)
>> CH-1015 Lausanne, Switzerland
>> +41 21 69 34 881
>> http://people.epfl.ch/265334
>> ------------------------------
>> *From:* q-e-developers-bounces at qe-forge.org <
>> q-e-developers-bounces at qe-forge.org> on behalf of José C. Conesa <
>> jcconesa at icp.csic.es>
>> *Sent:* Thursday, October 12, 2017 1:29 PM
>> *To:* q-e-developers at qe-forge.org
>> *Subject:* [Q-e-developers] on the calculation of Hubbard U values
>>
>>
>> Dear QE developers,
>>
>> I have seen in the last Psi-K highlight about the advances in the QE code
>> that version 6.2 (now at a release candidate status) will allow computing
>> ab initio U values for the DFT+U scheme using DFpT, so that supercells
>> would not be needed and the process would be much easier. Then, if one
>> wants to find U values considering the response not only for a specific
>> element but for all of them present in the material, i.e. computing the
>> complete (inverse) susceptibility matrices, it is necessary that Hubbard
>> parameters be considered for all elements in the material. But in its
>> present version, the code in files Modules/set_hubbard_l.f90 Modules/set_hubbard_n.f90
>> and PW/src/tabd.f90 only allows using Hubbard parameters for part of the
>> elements in the periodic table.
>>
>> For this reason I wish to make you a request: please include in those
>> files, in the final qe-6.2 version, all elements in the periodic table
>> (well, you may omit noble gases) so that each user does not need to modify
>> those files, and compile the executables again, every time that (s)he has
>> to consider a new element in the material for which U values should be
>> computed. This should not be difficult to do. I am aware that in some cases
>> it may be not clear which atomic subshell should be affected by the Hubbard
>> correction; for example, La might need to do it for d or f orbitals
>> depending on the compound, and In or Zn might be in a similar problem for p
>> and d orbitals. This could be solved just by adding a word of caution in
>> the manual.
>>
>> Hoping that this modification may be made,
>>
>> Best wishes,
>>
>> --
>> José C. Conesa
>> Instituto de Catálisis y Petroleoquímica, CSIC
>> Marie Curie 2, Cantoblanco
>> 28049 Madrid, Spain
>> Tel. (+34)915854766 <+34%20915%2085%2047%2066>
>>
>>
>> _______________________________________________
>> Q-e-developers mailing list
>> Q-e-developers at qe-forge.org
>> 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 <+39%200432%20558216>, fax +39-0432-558222
> <+39%200432%20558222>
>
>
> --
> José C. Conesa
> Director
> Instituto de Catálisis y Petroleoquímica, CSIC
> Marie Curie 2, Madrid, Spainwww.icp.csic.es
> Tel. (+34)915854766 <+34%20915%2085%2047%2066>
>
>
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org
> 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/20171013/a17b2aac/attachment.html>