[QE-users] Hubbard U+V for a large system

Andrii Shyichuk andrii.shyichuk at chem.uni.wroc.pl
Mon Nov 15 11:06:35 CET 2021


 

Dear Iurii, 

I've ran the calculations using JTH PAW pseudopotentials, the ones I
have tested and use typically. 

I get two issues: with my QE 6.7 compiled with Intel 19 I get a "Index
of the second rotated atom= 0   Error in routine symonpair (1):  Out of
bounds" error, while with QE 6.8 compiled with Intel 16 I get a weird
EOF error (https://gitlab.com/QEF/q-e/-/issues/415). Both builds have
natx increased and should accept an 80 atom cell. 
The in and out files are here.
https://drive.google.com/file/d/1XCQPA8j_Z9-R1os5YKMbVPINkeVCOofQ/view?usp=sharing

So, now I am waiting for the resolution of the EOF issue, which is some
strange compiler dependence of file read or write (I am not sure, but it
also shows up in the boron nitride HP tests, while other tests are
passed). 

Regarding the occupations - I've read the THEOS article on that long ago
and for some reason went with Gaussian smearing in particular. 
Smearing is not even needed for insulators, I could have used "fixed".
But, as long as I was studying systems with defects (including some
where occupied defect levels were at proximity of conduction band) - I
wanted to give my systems more convergence flexibility. Gaussian
smearing with small degauss gives a result very similar to the one with
the fixed occupations - in terms of optimized positions, forces and
energies. I might have had some convergence issues with "fixed" though,
which I did not have with "Gaussian". 

However, I've ran a test series, varying degauss and occupations kind.
For degauss=0.001 and 0.01, "gauss" and "mv" smearing result in the same
total force as "fixed", and the values is the same for k-point grids
2x2x2, 3x3x3, 4x4x4, 5x5x5, 6x6x6 (cell size is 10.4 Angstom though).
Wth degauss 0.1 and Gaussian smearing the force was still the same, and
went up at degauss 1.0. For MV, the increase happened at degauss=0.1. 
I found no significant run time difference between the smearing kinds -
but that was without defects, pure lutetium oxide. 
I think I will go with MV for further projects. 

 		grid >
 		2x2x2
 		3x3x3
 		4x4x4
 		5x5x5
 		6x6x6

 		occupations
 		degauss

 		fixed

 		0.046397
 		0.046403
 		0.046401
 		0.046402
 		0.046404

 		gauss
 		0.001
 		0.046368
 		0.046379
 		0.046377
 		0.046375
 		0.046389

 		gauss
 		0.01
 		0.046368
 		0.046379
 		0.046377
 		0.046375
 		0.046389

 		gauss
 		0.1
 		0.046488
 		0.046499
 		0.046496
 		0.046494
 		0.046508

 		gauss
 		1
 		0.071618
 		0.07521
 		0.07425
 		0.074528
 		0.074605

 		mv
 		0.001
 		0.046368
 		0.046379
 		0.046377
 		0.046375
 		0.046389

 		mv
 		0.01
 		0.046368
 		0.046379
 		0.046377
 		0.046375
 		0.046389

 		mv
 		0.1
 		0.064322
 		0.064315
 		0.064313
 		0.064315
 		0.064315

 		mv
 		1
 		0.064302
 		0.064879
 		0.064763
 		0.06543
 		0.064942

Finally, as DFT+U works fine, I am running tests to see if fixed
occupations will result in any significant difference in the calculated
U. 

Thank you. 
Andrii 

W dniu 2021-10-15 12:11, Iurii TIMROV napisał: 

> Dear Andrii, 
> 
> I received your input files (private communication) and I have investigated them. There are several issues with your inputs. 
> 
> * Setting Hubbard_V to 0.0 or 1.d-10 is not the same: 0.0 means that you do not consider V while 1.d-10 (or some other very small number) means that you consider V.
> * You put Hubbard_V(i,j,1) = 1d-10 in a weird way (I mean I do not understand the logic when you choose for which atoms to set Hubbard_V): you just need to put it on those atoms which you want to consider for the Hubbard V interactions (one per atomic type is enough, because the pw.x code will automatically consider all the other atoms of the same type as Hubbard atoms). In your system you have Hf, Lu, and O, and I see that you do not put V on Lu atoms: in this case you must list Lu atoms the last in the ATOMIC_POSITIONS card otherwise the HP code will stop (because you need to list first Hubbard atoms and then all the remaining non-Hubbard atoms, this is explained in the HP documentation).
> * You are using norm-conserving FHI98PP pseudopotentials. I recommend to use the SSSP library (PBEsol functional for solids): https://www.materialscloud.org/discover/sssp/table/efficiency [1]
> * Since you are using norm-conserving pseudopotentials, you are making a mistake by setting ecutwfc = 40 and ecutrho = 400 : ecutrho must be exactly 4 times larger than ecutwfc (not more, not less) - in fact, there is a warning in the pw.x output file (which you should inspect). For ultrasoft pseudopotentials and PAW this factor is typically 8-12 (one has to perform convergence tests).  
> * smearing = 'gaussian' : Gaussian smearing is not the most efficient one, I suggest to try MV.
> * degauss = 0.001 this is too small. Typical values are in the range 0.01-0.02 Ry but this depends on which k-mesh do you use, check here: http://theossrv1.epfl.ch/Main/ElectronicTemperature [2]
> * When you are preparing a QE input it is good to start with the QE input generator: https://www.materialscloud.org/work/tools/qeinputgenerator [3]
> * find_atpert = 2 in HP is not the default option: I would start with the default which is find_atpert = 1, it is better because the HP code checks the occupations of all atoms and perturbs non-equivalent atoms that have different occupations. Since in your system you have many O atoms it is likely that there are non-equilavent O atoms (this depends on distortions in your system).
> * You need to clarify whether you want only Hubbard V for Hf(5d)-O(2p) or also for Lu(5d)-O(2p). If you want to consider both then you need to set Hubbard_V also for Lu, otherwise put Lu the last in the ATOMIC_POSITIONS card.
> * Please try to make these changes and try to run again the code using QE v6.8. You system is too large to run on my workstation, I need to use a cluster, but before that try to make tests on your own and let us know if there still problems (as before, please share your input AND output files via e.g. Google Drive).
> 
> HTH 
> 
> Greetings, 
> Iurii 
> 
> --
> Dr. Iurii TIMROV
> Senior Research Scientist 
> Theory and Simulation of Materials (THEOS) 
> Swiss Federal Institute of Technology Lausanne (EPFL) 
> CH-1015 Lausanne, Switzerland
> +41 21 69 34 881 
> http://people.epfl.ch/265334 [4] 
> -------------------------
> 
> FROM: users <users-bounces at lists.quantum-espresso.org> on behalf of Iurii TIMROV via users <users at lists.quantum-espresso.org>
> SENT: Thursday, October 14, 2021 10:35:02 AM
> TO: Andrii Shyichuk; Quantum ESPRESSO users Forum
> SUBJECT: Re: [QE-users] Hubbard U+V for a large system 
> 
> Dear Andrii, 
> 
>> SCF run is fine, file hp.x run gives:
>> Index of the second rotated atom=           0
>> Error in routine symonpair (1):
>> Out of bounds 
> 
> It is strange that the pw.x codes works fine while you have some issues with hp.x. These two codes use the same routine symonpair. 
> 
> Which version of QE do you use? Can you share please your input and output files (via Google Drive) so that we can investigate your problem in more detail? 
> 
> Greetings, 
> 
> Iurii 
> 
> --
> Dr. Iurii TIMROV
> Senior Research Scientist 
> Theory and Simulation of Materials (THEOS) 
> Swiss Federal Institute of Technology Lausanne (EPFL) 
> CH-1015 Lausanne, Switzerland
> +41 21 69 34 881 
> http://people.epfl.ch/265334 [4] 
> -------------------------
> 
> FROM: users <users-bounces at lists.quantum-espresso.org> on behalf of Johannes Meusburger - STFC UKRI <Johannes.Meusburger at stfc.ac.uk>
> SENT: Wednesday, October 13, 2021 10:25:41 PM
> TO: Andrii Shyichuk; Quantum ESPRESSO users Forum
> SUBJECT: Re: [QE-users] Hubbard U+V for a large system 
> 
> Dear Andriii, 
> 
> As far as I know, the default settings limit DFT + U + V to 50 atoms. However, this should be readily adjusted by changing the natx parameter in the Modules/parameters.f90 (Modules/parameters.f90 · develop · QEF - Quantum Espresso Foundation / q-e · GitLab [5]) to your system size. 
> 
> Also, having a look at your input file I do not think that you should Hubbard_U(3) = 1d-10  AND Hubbard_V(3,3,1), since Hubbard_V(3,3,1) already refers to the on-site Hubbard U for atom 3.  To sum up, if you are using DFT + U use Hubbard_U, if you are using DFT + U + V just use the Hubbard_V keyword.  
> 
> The solutions to both of these problems are well described in the pw.x  input description (pw.x: input description (quantum-espresso.org) [6], hence I thought you might find it helpful to give it a read. Also, I highly recommend working your way through the examples on the QE github page (q-e/LiCoO2.scf.in at master · QEF/q-e · GitHub [7]). 
> 
> HTH, 
> 
> Johannes Meusburger 
> ISIS Neutron and Muon Source & Diamond Light Source & University of Exeter, UK 
> 
> -------------------------
> 
> FROM: users <users-bounces at lists.quantum-espresso.org> on behalf of Andrii Shyichuk via users <users at lists.quantum-espresso.org>
> SENT: Wednesday, October 13, 2021 8:52 PM
> TO: users at lists.quantum-espresso.org <users at lists.quantum-espresso.org>
> SUBJECT: [QE-users] Hubbard U+V for a large system 
> 
> Dear Users,
> 
> I'm trying to run a DFT+U+V Hubbard parameters calculation (hp.x) on a 
> system with 80 atoms.
> 
> SCF run is fine, file hp.x run gives:
> 
> Index of the second rotated atom=           0
> Error in routine symonpair (1):
> Out of bounds
> 
> How can the second rotated atom be zero?
> 
> My input is based on the YouTube "Tutorial on DFT+U+V using Quantum 
> ESPRESSO (v6.7)".
> The +U+V settings are:
> lda_plus_u = .true.
> lda_plus_u_kind = 2
> Hubbard_U(3) = 1d-10
> Hubbard_V(1,1,1) = 1d-10
> Hubbard_V(2,2,1) = 1d-10
> Hubbard_V(3,3,1) = 1d-10
> Hubbard_V(4,4,1) = 1d-10
> ...
> Hubbard_V(80,80,1) = 1d-10
> 
> Is it a bug, or is it just the question of some parameter tweaking?
> I've already increased natx to 150.
> 
> Thank you.
> Andrii Shyichuk, University of Wrocław.
> _______________________________________________
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu [8])
> users mailing list users at lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users 
> 
> This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.

  

Links:
------
[1] https://www.materialscloud.org/discover/sssp/table/efficiency
[2] http://theossrv1.epfl.ch/Main/ElectronicTemperature
[3] https://www.materialscloud.org/work/tools/qeinputgenerator
[4] http://people.epfl.ch/265334
[5] https://gitlab.com/QEF/q-e/-/blob/develop/Modules/parameters.f90
[6] https://www.quantum-espresso.org/Doc/INPUT_PW.html#idm471
[7]
https://github.com/QEF/q-e/blob/master/HP/examples/example10/reference/LiCoO2.scf.in
[8] http://www.max-centre.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20211115/d4e3126e/attachment.html>


More information about the users mailing list