Author Topic: Post-HF metal cluster calculations - issues with lastdiag  (Read 2652 times)

ChrisS

  • Newbie
  • *
  • Posts: 2
  • Karma: +0/-0
Post-HF metal cluster calculations - issues with lastdiag
« on: January 12, 2022, 03:13:38 PM »
I am currently trying to run RPA calculations on some platinum clusters. For this I am using ridft to us the resulting PBE orbitals for RPA, using a def2-QZVPP basis. I can successfully do this through a combination of heavy damping, many iterations, orbital shifts, etc. However, when these converge, it results in a negative HOMO-LUMO gap. This is a problem for performing RPA calculations, as it requires an aufbau population (cf. https://forum.turbomole.org/index.php?topic=531.0).

A solution to this was to use the $lastdiag keyword to force a last diagonalisation and obtain an aufbau population. This works well for unrestricted calculations and the subsequent RPA calculations are easy to perform. However, for restricted calculations, the use of $lastdiag results in a large, positive HOMO-LUMO gaps (~7 eV), which makes the RPA energies unphysical. I am using Turbomole 7.3.1 but found this issue across multiple versions

The problem does is not with the RPA, or DFT convergence, as the RPA works well for unrestricted calculations, and the DFT energies are reasonable. The issue seems to be with using $lastdiag with restricted DFT. I know that this is a issue that has been found in the past (https://forum.turbomole.org/index.php?topic=531.0) but found no solutions in the forum. Is there a way to solve this?

Finally, we tested several key words to see if they would have any effect on the large positive HOMO-LUMO gap (scfconv, scftol, denconv, dft gridsize, thime, thize, scforbitalshift, etc) but found that the only thing that made any difference was $scftol, the integral screening threshold. This was not consistent however and the HOMO-LUMO gap changed seemingly randomly, irrespective of $scftol:

$scftol / 10-x      HOMO-LUMO Gap/ eV
11                                      0.07
12                                      9.46
13                                      0.53
14                                      1.18
15                                      0.30
16                                      0.10
17                                      6.22
18                                      8.06

Do you have any insight into this or new suggestions that we could try?

Best wishes,

Chris

uwe

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 558
  • Karma: +0/-0
Re: Post-HF metal cluster calculations - issues with lastdiag
« Reply #1 on: January 13, 2022, 11:07:59 AM »
Hi Chris,

first, it has to be clarified whether or not this is a technical problem. To figure that out, the input is required which I'd like to ask you to send to the Turbomole support, or send a personal message.

Second, the $lastdiag keyword is usually only needed in cases the HOMO-LUMO gap is very close to zero. By default the Fock(KS) matrix is not diagonalized again to re-calculate the orbital energies in the last step when convergence is reached, because convergence does mean that energy, density, etc. do not change from one SCF iteration to the next. If it does happen nevertheless, this could be a hint that there are at least two different electronic states which are so close to each other that they should be considered as degenerated. Or a multi-reference case.

Did you try fractional occupation ($fermi) to check in DFT if this results in a proper integer occupation or if you get something like 0.5 occupation in two different orbitals?

Another option (with Turbomole versions 7.5.1 or 7.6) to use $arh keyword to enable the augmented Roothaan-Hall algorithm.

Best regards,
Uwe

ChrisS

  • Newbie
  • *
  • Posts: 2
  • Karma: +0/-0
Re: Post-HF metal cluster calculations - issues with lastdiag
« Reply #2 on: February 07, 2022, 03:22:11 PM »
Hi Uwe,

Thank you. I have sent you a message.

I have tried $fermi in the past and it never gives integer population for these clusters. I also had no success with the $arh keyword; it gave the same results as without.

Best wishes.

Chris