WARNING: HOMO-LUMO Gap is negativ

[tanguyv]

Hello,

I am doing test calculations with the DFT-D functional and I end-up with electronic results which puzzle me. The system is a dimer of two molecules (Tetrathiafulvalene and Tetracyanoquinodimethane) that are placed parallel to each other. I am doing an optimization of the geometry (using the b97-d functional with def2-TZVP as basis set) which seems to have successfully converged. However, if I am analyzing the orbitals with the keyword 'eiger', I obtain the following output:

 HOMO-LUMO Separation
   HOMO:   105.   104 a     -0.16564288 H =     -4.50737 eV
   LUMO:   104.   105 a     -0.19773654 H =     -5.38069 eV
   Gap :                    -0.03209367 H =     -0.87331 eV
        !! WARNING: HOMO-LUMO Gap is negativ !!

  106.   106 a                     -0.123486 H =        -3.360 eV
  105.   104 a        2.000        -0.165643 H =        -4.507 eV
  104.   105 a                     -0.197737 H =        -5.381 eV
  103.   103 a        2.000        -0.209867 H =        -5.711 eV
  102.   102 a        2.000        -0.246141 H =        -6.698 eV

I am then a bit puzzled that the calculation is labeled as successful while I obtain such meaningless results for a ground state calculation.

Do you know what could be the problem? Did I miss something in the input which could induce such strange behavior?

Thanks in advance for the help.

Best regards,

Tanguy Van Regemorter

[mpjohans]

Hello!

Negative HOMO-LUMO gaps, which are OK within the DFT model used, do occur from time to time. In this case, the gap is quite large, however, so I suspect it has converged to an excited state. (I haven't played around with the empirical dispersion correction too much, so perhaps larger negative gaps are more common with those, for some reason.) There's (at least) two things you can do to try to fix that:

1) Tighten the $scfconv and lower $orbitalshift values and restart. Because of those, you might need to increase the $scfdamp value, too. This could help.

2) Manually edit the "mos" file, and move orbital 105 data before orbital 104, change labels, and restart. This usually helps.

Have a nice day,
    Mikael J.
    http://www.iki.fi/~mpjohans

[uwe]

Hi,

is most such cases the problem came from

$scforbitalshift closedshell

which can cause two orbitals to switch positions. To my knowledge, it always helped to switch to the default

$scforbitalshift automatic=0.1

Unfortunately some older define versions added the closedshell keyword instead of automatic in some cases, especially when running define with an existing input.

Regards,

Uwe

[tanguyv]

Hello!

Thanks for your answers.

I checked the control file and the default parameter after using define is $scforbitalshift automatic=0.1. I tried then the proposition of Mikael. I let you know if it solves the problem.

Best regards,

Tanguy