obasis documentation/features

[PaulWAyers]

Executive summary: improve documentation; allow label-to-basis conversion; convert-to-primitives functionality.

We should make sure that obasis (both code and docs) are thoroughly documented. (We've had several questions about it in the last few days).

It would be useful to have a label-to-basis-index and basis-index-to-label functionality, similar to PySCF. It would not need to be implemented exactly like this, but it would be nice to have functionality that, for a given basis function (say, the 17th) would tell you its type, contraction coefficients, exponents, center etc. (e.g., that it was the 3rd dz^2 basis function on the second atomic center). Similarly, it would be nice to be able to ask for a specific type of basis function (e.g., the 3rd dz^2 on a specified atom) and return the basis index.

Finally, it would be nice to have a tool to convert a contracted basis set (and its MOs) into a completely decontracted (100% primitives) format. This is especially useful for dumping *.wfx and *.wfn. It's also useful (very occassionally) since decontracted basis sets are often preferable for small, highly-charged polycations (e.g., isoelectronic series).

[FarnazH]

Would it be also useful to make the functionality for converting between Cartesian and Pure types more transparent and user-friendly, so that the user can convert between them, and choose what type to dump when writing out a file format?

[PaulWAyers]

Yes. And it would be nice to have a lot of other functionality. E.g.,

1. Convert from L1 normalized to L2 normalized to un-normalized basis set conventions. It's especially important since integrals and *.wfn and *.wfx usually use unnormalized Gaussians.
2. [from Farnaz] Convert from pure-to-Cartesian basis sets.
3. [from my first issue] Convert from contracted to uncontracted basis sets. (Also useful for *.wfn and *.wfx, but also the cse where you want to take a neutral-atom basis and apply it to a highly charged system).

[PaulWAyers]

@tovrstra do you have notes on the L1 norm for spherical Gaussian basis functions? The L1 normalization is "supported" but not really documented.

[tovrstra]

It is not implemented yet. The field was introduced because it seemed useful for density-fitting basis sets, but it was not needed yet with the current file formats.

[PaulWAyers]

Based on a fast literature search, I think the main normalization for density-fitting basis sets is either none or using the Coulomb normalization, where the Coulomb interaction of the basis function with itself is 1.0. I sent Ali a rough idea for L1 normalization of spherical basis functions. The Coulomb normalization leads to Boys-function-hell I think which may not be what we want to do in IOData?

[tovrstra]

Coulomb normalization seems indeed a bit inconvenient and is also a form of L2 normalization. In principle one only needs the limit of the Boys function for r->0, which may still be relatively easy.

For L1 normalization, a simple choice would be to require the multipole moment of the basis function (of corresponding ℓ and m value) to be one. This is not a L1 norm in the strict sense because its definition depends on the quantum numbers of the AO basis function.

[PaulWAyers]

That seems sensible. So one would take
Integral(x,y,z) (L1NormedGaussian(r)*Y(ℓ,m))*Y(ℓ,m) dxdydz = 1.0
That's very easy since it boils down to just L1-norming the radial factor of the Gaussian. It's not quite consistent with the corresponding Cartesian case (where the L1 norm can be computed) but I doubt this feature gets used that much (more likely to use unnormalized Gaussians here, probably).

[PaulWAyers]

Yep, let's talk on Monday. The main urgency is that @Ali-Tehrani is refactoring/extending obasis right now.

[tovrstra]

I will start splitting this up in smaller and more focused issues to make it easier to address the points mentioned above. It is too much for one issue.

[tovrstra]

Everything should be mentioned now in the separate issues. I'm closing this one.