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

[Teodoro Laino]

Again: one should specify that if you use the ADDED_MOS keyword these 
(in post-processing) will be considered like occupied orbitals 
(irrespective of their occupation number) : see example provided by "zh".

I'm not discussing whether HOMO or LUMO definition holds when using 
smearing or not.
I'm just saying that in MO_CUBES it is quite clear what a HOMO or a LUMO 
is, in standard conditions. And the same definition still holds if one 
classifies the ADDED_MOS as occupied orbitals (even if their occupation 
number is zero).
Alternatively after one uses the ADDED_MOS, you should remove the 
ADDED_MOS which have occupation number set to zero from the set of 
occupied orbitals. This would definitely make all consistent..

Teo


marci wrote:
> I do not fully agree. The ADDED_MOS keyword is mainly thought for
> calculations
> with smeared occupation numbers. In this case the number of partially
> occupies MOs
> is larger than the number of electrons, and definition homo and lumo
> are not anymore a good
> way to classify the MOs
> True is that in the case illustrated by "zh"
> there is no need to add MOs for the SCF and the unoccupied
> states can be safely calculated a posteriori just for printing
> purposes,
> i.e. ADDED_MOS can be set to zero.
>
> cheers
> marcella
>
> On Mar 3, 11:12 am, Teodoro Laino <teodor... at gmail.com> wrote:
>   
>> 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.
>>>>         
>
>