Questions on vector space design for discussion

[yzhang-23]

PR Type

• [ ] Breaking change
• [X] Feature
• [ ] Patch

Brief Description Bring some questions on the design of vector space for discussion. Please see the texts in brackets starting with (Yu: ...).

Not In Scope

PR Checklist

• [ ] Is documented
• [ ] Is tested
• [ ] Adheres to applicable organization standards

TODOs

• [ ] Implement the new classes.

[ryanmrichard]

If what you are adding is helpful to you, great, but before you spend too much time on this I did want to chime in and say this doesn't look like it's getting to the matter at hand.

The general idea of the vector space component is that it should be possible to compose with objects in this component akin to how the theories do. As an example, a spin orbital is a product of a spatial orbital and a spin function. It should therefore be possible, in code, to create a set of spatial orbitals, create a set of spin functions and take their product. The architecture I wrote up established what the concepts at play were (and following the object-oriented practice of one concept per class, the classes we need). It did not provide guidance on how to actually implement the classes.

What you need to do is work out:

• given an arbitrary class of the vector space (VS) component what should the user be able to do?
• if the user knows they have a CartesianSpace object what should the user be able to do?
• if the user has a SpinSpace object what should they be able to do?
• if the user has a AOSpace object what should they be able to do?
• if the user has a ProductSpace<R...> object what should they be able to do?
• what info does ProductSpace<R...> need from the various types (the R...) to function according to the various point?

Working out the above can theoretically be done by writing down UML diagrams, but even I think it's easier to do it with pseudocode (allows you to avoid needing to worry about all the const and & etc.). My point being if you're trying to work out say the API of the CartesianSpace I'd start with something like:

CartesianSpace r0; // Makes a 0-dimensional CartesianSpace
CartesianSpace r1(1); // Makes a 1-dimensional CartesianSpace
CartesianSpace r2(2); // Makes a 2-dimensional CartesianSpace
//etc.

//Inspecting the size of the space
assert(r0.size() == 0); // No basis functions
assert(r1.size() == 1); // 1 basis functions
assert(r2.size() == 2); // 2 basis functions

// Resizing the space
r0.resize(1); // Now a 1-diemensional space

// repeat above for other members

What I think you're going to find is that when you try to work out the API of:

ProductSpace<AOSpace, SpinSpace> so0;

the mix-match of APIs is going to break the implementation.

As a slight aside, to be clear, the spatial orbitals of a spin orbital live in an AOSpace not a CartesianSpace. So the spin orbitals you are after are of type ProductSpace<AOSpace, SpinSpace> not ProductSpace<CartesianSpace, SpinSpace>.

[yzhang-23]

If what you are adding is helpful to you, great, but before you spend too much time on this I did want to chime in and say this doesn't look like it's getting to the matter at hand.

The general idea of the vector space component is that it should be possible to compose with objects in this component akin to how the theories do. As an example, a spin orbital is a product of a spatial orbital and a spin function. It should therefore be possible, in code, to create a set of spatial orbitals, create a set of spin functions and take their product. The architecture I wrote up established what the concepts at play were (and following the object-oriented practice of one concept per class, the classes we need). It did not provide guidance on how to actually implement the classes.

What you need to do is work out:

* given an arbitrary class of the vector space (VS) component what should the user be able to do?

* if the user knows they have a `CartesianSpace` object what should the user be able to do?

* if the user has a `SpinSpace` object what should they be able to do?

* if the user has a `AOSpace` object what should they be able to do?

* if the user has a `ProductSpace<R...>` object what should they be able to do?

* what info does `ProductSpace<R...>` need from the various types (the `R...`) to function according to the various point?

Working out the above can theoretically be done by writing down UML diagrams, but even I think it's easier to do it with pseudocode (allows you to avoid needing to worry about all the const and & etc.). My point being if you're trying to work out say the API of the CartesianSpace I'd start with something like:

CartesianSpace r0; // Makes a 0-dimensional CartesianSpace
CartesianSpace r1(1); // Makes a 1-dimensional CartesianSpace
CartesianSpace r2(2); // Makes a 2-dimensional CartesianSpace
//etc.

//Inspecting the size of the space
assert(r0.size() == 0); // No basis functions
assert(r1.size() == 1); // 1 basis functions
assert(r2.size() == 2); // 2 basis functions

// Resizing the space
r0.resize(1); // Now a 1-diemensional space

// repeat above for other members

What I think you're going to find is that when you try to work out the API of:

ProductSpace<AOSpace, SpinSpace> so0;

the mix-match of APIs is going to break the implementation.

As a slight aside, to be clear, the spatial orbitals of a spin orbital live in an AOSpace not a CartesianSpace. So the spin orbitals you are after are of type ProductSpace<AOSpace, SpinSpace> not ProductSpace<CartesianSpace, SpinSpace>.

I will try to describe the usage of such classes. Of course spin orbitals come from products of AOSpace and SpinSpace, not from CartesianSpace.

[yzhang-23]

For SpinSpace, I want to bring an open question for discussion: currently I have not assign any actual spin eigenfunctions to a SpinSpace. Only the spin channels labelled by their spin values are available in the class. Actual spin eigenfunctions may not be necessary for constructing spin orbital spaces such as ASOSpace or MSOSpace, but I'm not so sure whether they are necessary for future applications. Any idea on this issue?

[hjjvandam]

For UHF the alpha electron orbitals are different from the beta electron orbitals. So we would need to be able to have different eigenvectors for both. For RHF and ROHF the alpha and beta electron orbitals are the same. In ROHF it is just that the number of alpha electrons is different from the number of beta electrons.

[jwaldrop107]

Closing as outdated.