Questions about printing out unoccupied molecular orbitals (LUMO, LUMO+x)

[marci]

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.