Intuitive representation of molecular basis set

[tovrstra]

Our current representation of molecular Gaussian basis sets is not ideal:

• not very intuitive
• not very pythonic
• mainly geared toward the FCHK format, but it requires non-intuitive manipulations for all other formats.

The Gaussian orbital basis can be described by a single attribute:

obasis of the type namedtuple('OBasisInfo', ['centers', 'shells', 'type', 'conventions'])

where:

• centers is an array with of shape (ncenter, 3)
• shells is a list of objects of the type namedtuple('Shell', ['icenter', 'iatom', 'angmoms', 'exponents', 'contractions'])
• type: any of 'cart' or 'pure'
• conventions: a dictionary with as key an angular momentum character ('s', 'p', ...) and as value a list of basis function strings, e.g.

  # alphabetically ordered Cartesian functions
  ['1'],
  ['x', 'y', 'z'],
  ['xx', 'xy', 'xz', 'yy', 'yz', 'zz'],
  # wikipedia ordered real solid spherical harmonics
  ['s'],
  ['pc1', 'pc0', 'ps1],
  ['dc2', 'dc1', 'dc0', 'ds1', 'ds2'],

  Any of these strings can be prefixed with a minus sign (-) to denote sign conventions.

where:

• icenter: an integer referring to a row of centers
• iatom: an integer for the atom on which the shell is centered, or None. This could be convenient when implementing Pulay forces.
• angmoms: a string where each character represents an angular momentum of one of the contractions in the shell. The length equals the number of contractions: len(angmoms)=ncon. Any of the following can be used: ["s", "p", "d", "f", "g", "h", "i", "k", "l", "m", "n", "o", "q", "r", "t", "u", "v", "w", "x", "y", "z", "a", "b", "c", "e"]
• exponents: an array of exponents of primitives, with shape (nprim,).
• contractions: an array with contraction coefficients, with shape (ncon, nprim). These coefficients assume that the primitives are L2-normalized, but contractions are not necessarily normalized.

Remarks:

• A main downside of this idea is that IOData objects will become harder to store as npz files.
• Attributes permutation and signs can be removed and should be replaced by convenience functions.

Example of an iterator over all basis functions:

def iterate_basis(obasis):
    for shell in obasis.shells:
        for angmom in shell.angmoms:
            for convention in obasis.conventions[angmom]:
                yield shell.icenter, shell.iatom, angmom, convention

[FarnazH]

1. Is there any reason not to use center as an attribute in the namedtuple instead of icenter? This gives namedtuple('Shell', ['center', 'type', 'angmoms', 'exponents', 'concoeffs']) which gives better access to the shell.center instead of centers[shell.icenter].

2. I think the last line of code snippet, ibasis += 1, should be indented to be included inside the last for loop, no?

[tovrstra]

For point 1, it is convenient to group shells by centers with integer indices. I'll fix point 2.

[FarnazH]

See https://github.com/theochem/iodata/blob/master/iodata/wfn.py#L141

[PaulWAyers]

I think we were going to change shell ordering in the next version of HORTON? Should we do that now? https://github.com/theochem/cgbasis/issues/2

[tovrstra]

@PaulWAyers Now would be good.

[PaulWAyers]

Do we know what that convention is? I looked quickly but didn't see it....

[tovrstra]

IOData should not fix this convention. The purpose of this issue is to define how the convention is represented. When implementing Gaussian integrals, you can decide which convention you use, as long as it can be described it with the data structure described here.

[kimt33]

For implementing gbasis, we need a nice data structure from which we can build the rest of the code. We plan on creating a class for the set of contracted Cartesian Gaussians of the same angular momentum. I know there are plans to come up with some data structure for orbitals here, but we can refactor or make a wrapper around gbasis if necessary.

See https://github.com/theochem/gbasis/issues/2

[PaulWAyers]

I think the idea will be that flexible basis sets are allowed in iodata, and that iodata can convert from one basis-set representation to another. As such, one thing iodata could do is build whatever basis-set representation gbasis uses, or pass to gbasis the data so that gbasis porcelain can build its own representation. In terms of modularity, probably the latter is a bit better..but I'm not sure.

[tovrstra]

@PaulWAyers I fully agree. I would go for the second option, where gbasis knows how to interpret a a namedtuple from iodata.