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

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


 

Dear Paolo, 

I did the tests with Intel 19, compiled in the same way as the Intel 16
version. 
They've had identical make.inc files, except for the MKL path. 

BN is now fine, but CrI3 PW fails. 
I've posted the respective files in the issue page. 
https://gitlab.com/QEF/q-e/-/issues/415

Best regards. 
Andrii 

W dniu 2021-11-15 13:53, Paolo Giannozzi napisał: 

> On Mon, Nov 15, 2021 at 11:07 AM Andrii Shyichuk via users <users at lists.quantum-espresso.org> wrote: 
> 
>> 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
> 
> I am puzzled (and it is not the first time) by such an approach to computer problems. The first thing to do is to try QE 6.8 with Intel 19. If it works, problem solved. If it doesn't, it might be an indication of a QE problem. What is reported here is an old QE version with a new compiler, and a new QE version with an old compiler. Why should anybody spend time on a problem that might have meanwhile disappeared? 
> 
> Paolo 
> 
> (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.  
> 
> _______________________________________________
> 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

  -- 

Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 206, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222

  

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/2773b4a3/attachment.html>


More information about the users mailing list