[CP2K:2610] Re: Questions about printing out unoccupied molecular orbitals (LUMO, LUMO+x)

[Teodoro Laino]

Just a comment:

It is not the definition of the NHOMO and NLUMO to be not clear in 
MO_CUBES rather it is the description of the keyword ADDED_MOS.
One should specify in that keyword that the ADDED MOS are considered 
like HOMOS in post-processing calculations (although they are not filled).

Teo


marci wrote:
> Hi
>
> Actually, I do not think this is really a problem of the
> calculations,
> but a misunderstanding in the definition of the MOs.
> When you use the keyword ADDED_MOS together with the
> diagonalization scheme,  at each SCF step all the occupied MOs
> plus a number of unoccupied MOs equal to the ADDED_MOS are
> computed (eigenvectors, eigenvalues, and occupation numbers).
> If you print through the section
> &MO
>  ...
> &END
> you can get the related eigenvalues and occupations, and from these
> the gap.
>
> Now, if on top of these you print through the section
> &MO_CUBES
> ...
> &END
> and you require NLUMO different from zero,
> NLUMO states are computed a posteriori, in addition to those
> already computed along the SCF procedure. These are therefore higher
> in energy, and do not correspond to the lowest LUMOS, but to
> the lowest states laying above those already computed.
> If you want the cubes of the lowest unoccupied states, and you have
> ADDED_MOS
> different from zero, you should consider that some of them are
> obtained with
> the keyword NHOMO.
> I agree that in this situation the keyword names NHOMO and NLUMO in
> the section MO_CUBES
> are misleading.
>
> kind regards
> marcella
>
> On Mar 2, 5:17 pm, zh <vale... at gmail.com> wrote:
>   
>> In my test calculations, I also found another problem:
>> If the keyword "ADDED_MOS" in the section &SCF is set as 0 or 1, the
>> LUMO and LUMO+1 orbitals of C6H6 molecule obtained with cp2k will be
>> similar to those obtained with other codes.
>>
>> In the log file, there are two values printed out for the LUMO-HOMO
>> gap.
>>
>> The first value of LUMO-HOMO gap is printed out due to the following
>> keyword:
>> "
>>     &MO
>>         EIGENVALUES
>>         OCCUPATION_NUMBERS
>>       &END MO
>> "
>> This one is reasonable. That is why I say that the unoccupied
>> molecular orbitals are already obtained before calling "make_lumo()".
>>
>> The second value of LUMO-gap is printed out due to the following
>> keyword:
>> "
>> &MO_CUBES
>>          NHOMO  3
>>          NLUMO  10
>>          WRITE_CUBE .TRUE.
>>       &END MO_CUBES
>> "
>> While the second one is quite larger than the first one.
>>     
>
>