[gpaw-users] Generating new basis sets for LCAO mode

Ask Hjorth Larsen asklarsen at gmail.com
Fri Apr 26 12:43:19 CEST 2013


Hi Eric

2013/4/24 Eric Hermes <ehermes at chem.wisc.edu>:
> Hello,
>
> I have a couple of questions regarding how GPAW basis sets for LCAO mode
> are generated, specifically with regards to platinum.
>
> First, I would like to point out what I think is a problem with the
> basis sets that are packaged with the most recent setups tarball. For
> the DZP basis set, all of the D-block metals have either D-like or
> P-like polarization functions instead of F-like.  This is different from
> the DZP basis sets generated by using all default parameters with
> gpaw-basis (version 0.9.1.10133), which does generate F-like
> polarization functions.  I mentioned this in the IRC channel, and Ask
> agreed that the basis sets in the setups tarball are wrong.
>
> Moreover, I am somewhat confused as to why some of the polarization
> functions in the basis sets that I generate with my gpaw-basis are
> P-like (Co, Cu, and Au are all P-like, whereas Ni, Rh, Pd, Ag, Ir, and
> Pt are all F-like).  From a physical standpoint, it seems to me that a
> polarization function for any element with D valence orbitals should
> have F-like polarization functions.  It is not clear to me what the
> physical interpretation of a P-like polarization function would be given
> that an orbital can only really be polarized by a function that has less
> symmetry.

You're right that transition metals should generally have p-type
polarization.  Unfortunately one has to specify this manually when
generating a basis.  That is: gpaw-basis --lpol=1 [....]

>
> The --help information for gpaw-basis says that the default behavior for
> generating polarization functions is to assign it the lowest l which is
> not among the valence states.  This ties into my second question, as it
> turns out that gpaw-basis is doing exactly what it says. Co, Cu, and Au
> do not include their largest occupied P orbitals in their valence count,
> whereas the other elements I have listed do.  This means that Co has 9
> electrons in its valence whereas Rh and Ir both have 15, and Cu and Au
> have 11 electrons in their valence whereas Ag has 17.  Is there some
> reason for this difference?  Even though these elements do not have P
> orbitals in their valence, does it not still make sense to use F-like
> polarization functions?  Also, is it possible to generate a new setup
> and basis for platinum along the lines of Co, Cu, and Au such that it
> only has 10 electrons in its valence which is composed of the 6S and 5D
> orbitals?

Unfortunately this would be difficult from the command line.  In the
Python example which you also mention below:

  https://wiki.fysik.dtu.dk/gpaw/documentation/lcao/lcao.html#advanced-basis-generation

change the import line to 'from gpaw.configurations import
parameters_extra' and get the Ag parameters from there.

We should probably improve this for the next version. :)

>
> I have also been trying to figure out how to generate a basis for Pt
> that includes its empty 6P orbital, following the guide on the wiki
> (https://wiki.fysik.dtu.dk/gpaw/documentation/lcao/lcao.html#advanced-basis-generation).
> I have only just now figured out how do to this, as the page linked has
> a typo (should be jvalues instead of lvalues).  I also found this syntax
> to be fairly confusing, and it is still not clear to me how to parse the
> argument that jvalues accepts.  Specifically, why is it a list rather
> than an integer indicating how many valence orbitals to include?

The empty states are very extended and one wouldn't generally want
them in a localized basis set.  They are therefore not included.

It's a list because it's not always clear which should be the "first"
orbital (some states coming from the generator are unoccupied,
unbound, ...).

(Thanks for using these functions so I'm reminded to improve them.
However it will take some days before I have time.)

>
> Finally, I am curious as to how valence atomic orbitals are generated
> for e.g. double-zeta and triple-zeta basis sets.  I noticed when playing
> around with generating basis sets for Pt that all primitives in the dzp
> basis are included in the tzp basis, and that the only addition were a
> set of tighter primitives.  It is my understanding that when increasing
> the number of primitives in GTOs such as going from 6-31G to 6-311G, the
> larger basis set is typically more diffuse in character.  Is there any
> particular reason that the basis sets for GPAW add tighter functions
> rather than more diffuse functions with increasing zeta?

Cutoffs can be specified manually, or it uses a default list which is
pretty arbitrary.  You're right that a more intelligent choice
automatic exists.

>
> Thanks for helping me understand the way GPAW handles LCAO and basis
> sets, and I apologize for the overly long email.
>
> Eric Hermes

No problem, thanks for mentioning these issues.  I'm not sure that I
answer everything entirely, so don't hesitate to send further e-mails
if necessary although I may delay some days in answering.

Regards
Ask


More information about the gpaw-users mailing list