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

José Carlos Conesa jcconesa at icp.csic.es
Fri Oct 13 10:53:49 CEST 2017


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> on behalf of Paolo Giannozzi 
> <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 
> <mailto: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
>     <mailto:q-e-developers-bounces at qe-forge.org>
>     <q-e-developers-bounces at qe-forge.org
>     <mailto:q-e-developers-bounces at qe-forge.org>> on behalf of José C.
>     Conesa <jcconesa at icp.csic.es <mailto:jcconesa at icp.csic.es>>
>     *Sent:* Thursday, October 12, 2017 1:29 PM
>     *To:* q-e-developers at qe-forge.org <mailto: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 responsenot 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 <tel:+34%20915%2085%2047%2066>
>
>
>     _______________________________________________
>     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
>

-- 
José C. Conesa
Director
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Madrid, Spain
www.icp.csic.es
Tel. (+34)915854766

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20171013/3f4d403a/attachment.html>


More information about the developers mailing list