You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some cases, it is useful to transform arrays in IOData objects from one basis set to another. A preliminary implementation can be found in #175. A fully general implementation has a few weaknesses, which require some caution:
Lack of numerical stability. For two common types of transformations, simple and robust transformations exist, see Decontraction of basis sets #258 and Conversion to Cartesian basis sets #259. One option to reduce the numerical trouble is to make the transformation block diagonal with one atom per block. (This also makes it less general.)
When the two basis sets are sufficiently different, the transformation becomes a projection and the orbitals will not remain orthonormal after transformation. An (optional) normalization should be implemeted. Such a renormalization may also clean up some of the numerical artifacts from the previous point but it should not be considered as a safe solution for the numerical issues. Even after cleaning up, there may be data loss due to weak numerics.
@Ali-Tehrani had a very elegant algorithm he found for doing this. His way should be as stable as this can be. So I'd defer this issue to him.
The good news is that it should be possible in a very general way, with options for atom-blocking and renormalization easy possible embellishments. Ill-conditioning should be mainly (always?) associated with large basis sets (near-linear-dependence). In such cases, choosing a sensible (and clearly documented) resolution of the (near) ambiguity does not seem problematic to me.
(This was originally mentioned in #146.)
In some cases, it is useful to transform arrays in IOData objects from one basis set to another. A preliminary implementation can be found in #175. A fully general implementation has a few weaknesses, which require some caution:
This issue depends on #238.
The text was updated successfully, but these errors were encountered: