Re: [QE-users] hp.x Error in routine cdiaghg (270): problems computing cholesky

2024-01-25 Thread Timrov Iurii
Dear Simon,

You can compute Hubbard parameters using HP on top of the metallic ground state 
(i.e. with U=0 for your system). Just do one scf with smearing in that case.

> Would you suggest to take a parameter set from this (e.g 
> LVO_5.0_2.7_0.0/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.3585   13.4614: 1.1029) and start the HP scheme from there on?

Do you mean that you used U=5 eV for La-4f, U=2.7 for V-3d, and U=0 for O-2p? I 
would try smaller starting U value for La-4f, e.g. 3.2 eV with ortho-atomic 
orbitals [see PRR 2, 033265 (2020)]. So maybe check first whether you still 
have a gap with U=3.2 eV for La-4f?

HTH

Iurii

--
Dr. Iurii TIMROV
Tenure-track scientist
Laboratory for Materials Simulations (LMS)
Paul Scherrer Institut (PSI)
CH-5232 Villigen, Switzerland
+41 56 310 62 14
https://www.psi.ch/en/lms/people/iurii-timrov

From: Simon Imanuel Rombauer 
Sent: Thursday, January 25, 2024 17:20
To: Timrov Iurii ; users@lists.quantum-espresso.org 

Subject: Re: [QE-users] hp.x Error in routine cdiaghg (270): problems computing 
cholesky

Sending again since I feel it didn't work.
Am Donnerstag, Januar 25, 2024 12:59 CET, schrieb "Simon Imanuel Rombauer" 
:

> Dear Iurii,
>
> thank you for your response, yes I have noticed this, I thought HP can start 
> from this 'false state' and calculate the U parameters to correctly reflect 
> the Mott-insulator behavior.
> I also computed a few scf DFT+U with U value of V-3d ranging from 2.7 - 2.9 
> eV, many of which turned out to be metallic. See (LVO_U(La-4f)_U(V-3d_V(O-2p 
> V-3d))):
>
> LVO_5.0_2.7_0.0/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.3585   13.4614: 1.1029
> LVO_5.0_2.7_0.15/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.7936   12.7687: -0.0249
> LVO_5.0_2.7_0.3/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.8425   12.8166: -0.0259
> LVO_5.0_2.8_0.0/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.4686   13.3603: 0.8917
> LVO_5.0_2.9_0.0/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.7631   12.7638: 0.0007
> LVO_5.0_2.9_0.15/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.3092   13.5493: 1.2401
> LVO_5.0_2.9_0.3/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.4914   13.4507: 0.9593
> LVO_6.0_2.7_0.0/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.8108   12.8112: 0.0004
> LVO_6.0_2.7_0.15/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.8090   12.7859: -0.0231
> LVO_6.0_2.8_0.0/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.4816   13.3813: 0.8997
> LVO_6.0_2.8_0.15/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):13.0800   12.6079: -0.4721
> LVO_6.0_2.8_0.3/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.5317   13.4616: 0.9299
> LVO_6.0_2.9_0.0/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):13.0412   12.5850: -0.4562
> LVO_6.0_2.9_0.15/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.3227   13.5668: 1.2441
> LVO_6.0_2.9_0.3/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.4946   13.4855: 0.9909
> LVO_7.0_2.7_0.0/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):13.0819   12.6240: -0.4579
> LVO_7.0_2.7_0.15/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):13.1313   12.6651: -0.4662
> LVO_7.0_2.7_0.3/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):12.8713   12.8486: -0.0227
> LVO_7.0_2.8_0.0/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):13.0475   12.5857: -0.4618
> LVO_7.0_2.8_0.15/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):13.0963   12.6256: -0.4707
> LVO_7.0_2.8_0.3/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):13.2079   12.7589: -0.449
> LVO_7.0_2.9_0.0/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):13.0322   12.5719: -0.4603
> LVO_7.0_2.9_0.15/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):13.0812   12.6120: -0.4692
> LVO_7.0_2.9_0.3/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):13.1948   12.7461: -0.4487
> LVO_8.0_2.7_0.0/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):13.1005   12.6553: -0.4452
> LVO_8.0_2.7_0.15/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):13.1584   12.6600: -0.4984
> LVO_8.0_2.8_0.0/scf2.out:  highest occupied, lowest unoccupied level 
> (ev):13.1190   12.6864: -0.4326
> LVO_8.0_2.8_0.

Re: [QE-users] hp.x Error in routine cdiaghg (270): problems computing cholesky

2024-01-25 Thread Simon Imanuel Rombauer
lculation with 
> > smearing and then proceed to the HP calculation. Or, if the system is 
> > experimentally known to be insulating, you can add some finite value of U 
> > to V-3d states, which should open a gap and then proceed with the two-step 
> > SCF procedure plus HP.
> > 
> > HTH
> > 
> > Iurii
> > 
> > 
> > From: users  on behalf of Simon 
> > Imanuel Rombauer 
> > Sent: Wednesday, January 24, 2024 20:42
> > To: users@lists.quantum-espresso.org 
> > Subject: [QE-users] hp.x Error in routine cdiaghg (270): problems computing 
> > cholesky
> > 
> > Dear QE users,
> > 
> > for some time I am trying to find  suitable DFT+U+V parameters for 
> > orthorhombic LaVO3 band structure. I was limited with with computational 
> > resources so I tried to manually tune the parameters to match experimental 
> > band gab. This was very tedious and most calculations did not converge at 
> > all. Now I have more CPU cores to work with and want to use the hp.x code 
> > to calculate them using DFPT. I followed example 02 and 06 from the 
> > documentation, that is I first calculated scf of LVO using a smearing and 
> > starting mag. and then did a second scf run with fixed occupation and total 
> > mag. = 0. Then I split the HP calculation for each perturbed atom. It 
> > always ends with Error in routine  cdiaghg (270):   problems computing 
> > cholesky, I have tried to change mixing_mode, mixing_beta, higher ecutwfc 
> > and ecutrho, lowered the conv_thr but nothing worked. (input/output files 
> > appended)
> > 
> > Any idea is highly appreciated, also on how to speed up calculations, it 
> > still seems rather slow when calculating scf.
> > All the best and have a nice day
> > 
> > Simon Rombauer
> > Master Student Physics
> > University Augsburg
> > Germany
> > 
> > PS: I manually changed the occupation in the La PP from 5d to 4f, but even 
> > when I left the PP as it is and simply tried to calculate U for La-5d it 
> > crashed with the same error.

___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


Re: [QE-users] hp.x Error in routine cdiaghg (270): problems computing cholesky

2024-01-25 Thread Simon Imanuel Rombauer
Dear Iurii,

thank you for your response, yes I have noticed this, I thought HP can start 
from this 'false state' and calculate the U parameters to correctly reflect the 
Mott-insulator behavior. 
I also computed a few scf DFT+U with U value of V-3d ranging from 2.7 - 2.9 eV, 
many of which turned out to be metallic. See (LVO_U(La-4f)_U(V-3d_V(O-2p 
V-3d))): 

LVO_5.0_2.7_0.0/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  12.3585   13.4614: 1.1029
LVO_5.0_2.7_0.15/scf2.out:  highest occupied, lowest unoccupied level (ev): 
   12.7936   12.7687: -0.0249
LVO_5.0_2.7_0.3/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  12.8425   12.8166: -0.0259
LVO_5.0_2.8_0.0/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  12.4686   13.3603: 0.8917
LVO_5.0_2.9_0.0/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  12.7631   12.7638: 0.0007
LVO_5.0_2.9_0.15/scf2.out:  highest occupied, lowest unoccupied level (ev): 
   12.3092   13.5493: 1.2401
LVO_5.0_2.9_0.3/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  12.4914   13.4507: 0.9593
LVO_6.0_2.7_0.0/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  12.8108   12.8112: 0.0004
LVO_6.0_2.7_0.15/scf2.out:  highest occupied, lowest unoccupied level (ev): 
   12.8090   12.7859: -0.0231
LVO_6.0_2.8_0.0/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  12.4816   13.3813: 0.8997
LVO_6.0_2.8_0.15/scf2.out:  highest occupied, lowest unoccupied level (ev): 
   13.0800   12.6079: -0.4721
LVO_6.0_2.8_0.3/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  12.5317   13.4616: 0.9299
LVO_6.0_2.9_0.0/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  13.0412   12.5850: -0.4562
LVO_6.0_2.9_0.15/scf2.out:  highest occupied, lowest unoccupied level (ev): 
   12.3227   13.5668: 1.2441
LVO_6.0_2.9_0.3/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  12.4946   13.4855: 0.9909
LVO_7.0_2.7_0.0/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  13.0819   12.6240: -0.4579
LVO_7.0_2.7_0.15/scf2.out:  highest occupied, lowest unoccupied level (ev): 
   13.1313   12.6651: -0.4662
LVO_7.0_2.7_0.3/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  12.8713   12.8486: -0.0227
LVO_7.0_2.8_0.0/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  13.0475   12.5857: -0.4618
LVO_7.0_2.8_0.15/scf2.out:  highest occupied, lowest unoccupied level (ev): 
   13.0963   12.6256: -0.4707
LVO_7.0_2.8_0.3/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  13.2079   12.7589: -0.449
LVO_7.0_2.9_0.0/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  13.0322   12.5719: -0.4603
LVO_7.0_2.9_0.15/scf2.out:  highest occupied, lowest unoccupied level (ev): 
   13.0812   12.6120: -0.4692
LVO_7.0_2.9_0.3/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  13.1948   12.7461: -0.4487
LVO_8.0_2.7_0.0/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  13.1005   12.6553: -0.4452
LVO_8.0_2.7_0.15/scf2.out:  highest occupied, lowest unoccupied level (ev): 
   13.1584   12.6600: -0.4984
LVO_8.0_2.8_0.0/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  13.1190   12.6864: -0.4326
LVO_8.0_2.8_0.15/scf2.out:  highest occupied, lowest unoccupied level (ev): 
   12.8723   12.8683: -0.004
LVO_8.0_2.9_0.0/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  12.8057   12.8032: -0.0025
LVO_8.0_2.9_0.15/scf2.out:  highest occupied, lowest unoccupied level (ev): 
   12.8566   12.8521: -0.0045
LVO_8.0_2.9_0.3/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  12.9079   12.9012: -0.0067

Would you suggest to take a parameter set from this (e.g 
LVO_5.0_2.7_0.0/scf2.out:  highest occupied, lowest unoccupied level (ev):  
  12.3585   13.4614: 1.1029) and start the HP scheme from there on?

All the best,
Simon

Am Donnerstag, Januar 25, 2024 12:43 CET, schrieb Timrov Iurii 
:

> Dear Simon,
> 
> If you check the output file of the second SCF calculation, you will see this:
>  highest occupied, lowest unoccupied level (ev):13.2680   12.9953
> 
> This means that the system is metallic, and hence your should not use a 
> two-step SCF procedure. Just perform the first SCF calculation with smearing 
> and then proceed to the HP calculation. Or, if the system is experimentally 
> known to be insulating, you can add some finite value of U to V-3d states, 
> which should open a gap and then proceed with the two-step SCF procedure plus 
> HP.
> 
> HTH
> 
> Iurii
> 
> 
> From: users  on behalf of Simon 
> Imanuel Rombauer 
> Sent: Wednesday, January 24, 2024 20:42
> To: users@lists.quantum-espresso.org 
> Subject: [QE-users] hp.x Error in routine cdiaghg (270): problems computing 
> cholesky

Re: [QE-users] hp.x Error in routine cdiaghg (270): problems computing cholesky

2024-01-25 Thread Timrov Iurii
Dear Simon,

If you check the output file of the second SCF calculation, you will see this:
 highest occupied, lowest unoccupied level (ev):13.2680   12.9953

This means that the system is metallic, and hence your should not use a 
two-step SCF procedure. Just perform the first SCF calculation with smearing 
and then proceed to the HP calculation. Or, if the system is experimentally 
known to be insulating, you can add some finite value of U to V-3d states, 
which should open a gap and then proceed with the two-step SCF procedure plus 
HP.

HTH

Iurii


From: users  on behalf of Simon 
Imanuel Rombauer 
Sent: Wednesday, January 24, 2024 20:42
To: users@lists.quantum-espresso.org 
Subject: [QE-users] hp.x Error in routine cdiaghg (270): problems computing 
cholesky

Dear QE users,

for some time I am trying to find  suitable DFT+U+V parameters for orthorhombic 
LaVO3 band structure. I was limited with with computational resources so I 
tried to manually tune the parameters to match experimental band gab. This was 
very tedious and most calculations did not converge at all. Now I have more CPU 
cores to work with and want to use the hp.x code to calculate them using DFPT. 
I followed example 02 and 06 from the documentation, that is I first calculated 
scf of LVO using a smearing and starting mag. and then did a second scf run 
with fixed occupation and total mag. = 0. Then I split the HP calculation for 
each perturbed atom. It always ends with Error in routine  cdiaghg (270):   
problems computing cholesky, I have tried to change mixing_mode, mixing_beta, 
higher ecutwfc and ecutrho, lowered the conv_thr but nothing worked. 
(input/output files appended)

Any idea is highly appreciated, also on how to speed up calculations, it still 
seems rather slow when calculating scf.
All the best and have a nice day

Simon Rombauer
Master Student Physics
University Augsburg
Germany

PS: I manually changed the occupation in the La PP from 5d to 4f, but even when 
I left the PP as it is and simply tried to calculate U for La-5d it crashed 
with the same error.
___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] hp.x Error in routine cdiaghg (270): problems computing cholesky

2024-01-24 Thread Simon Imanuel Rombauer
Dear QE users,

for some time I am trying to find  suitable DFT+U+V parameters for orthorhombic 
LaVO3 band structure. I was limited with with computational resources so I 
tried to manually tune the parameters to match experimental band gab. This was 
very tedious and most calculations did not converge at all. Now I have more CPU 
cores to work with and want to use the hp.x code to calculate them using DFPT. 
I followed example 02 and 06 from the documentation, that is I first calculated 
scf of LVO using a smearing and starting mag. and then did a second scf run 
with fixed occupation and total mag. = 0. Then I split the HP calculation for 
each perturbed atom. It always ends with Error in routine  cdiaghg (270):   
problems computing cholesky, I have tried to change mixing_mode, mixing_beta, 
higher ecutwfc and ecutrho, lowered the conv_thr but nothing worked. 
(input/output files appended)

Any idea is highly appreciated, also on how to speed up calculations, it still 
seems rather slow when calculating scf. 
All the best and have a nice day

Simon Rombauer
Master Student Physics
University Augsburg
Germany

PS: I manually changed the occupation in the La PP from 5d to 4f, but even when 
I left the PP as it is and simply tried to calculate U for La-5d it crashed 
with the same error.


LVO_Hubbard.7z
Description: Binary data
___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users