Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add orth interface function #2227

Draft
wants to merge 23 commits into
base: main
Choose a base branch
from
Draft

Add orth interface function #2227

wants to merge 23 commits into from

Conversation

sdrave
Copy link
Member

@sdrave sdrave commented Nov 20, 2023

This PR can be seen as an alternative approach to #2211. It adds an orth interface function that orthonormalizes a VectorArray by dispatching to various orthonormalization algorithms.

Main characteristics:

  • If pad=False (which is the default), the spans of V and the computed basis are supposed to agree. Thus, len(basis) <= len(V). By setting pad=True, it is ensured that len(basis) == len(V), potentially by adding random vectors to the span.
  • If hierarchical is True, the span of the first k vectors in V agrees with the span of the first k vectors in basis. I.e., we obtain a QR decomposition. Since orth returns the coefficients of V in the new basis as expected by lincomb, the returned array has to be transposed in order to get a QR decomposition.

The approach is based on the general observation that (more or less) everywhere in pyMOR, where qr (or gram_schmidt) is called, we actually want to orthonormalize a basis and do not care so much about the actual algorithm. Also, I think that orth fits better with the notion of a VectorArrray then QR decomposition. As such, I have replaced all calls to qr with orth. I wasn't always sure, of the resulting basis were needed. I see it as a feature of this approach that this has to be made explicit in orth calls. I also believe that a qr function would not really be needed in this case, or would act as an alias for orth.

This is meant as a basis for discussion. The implementation is ad-hoc and not fully tested. Argument names or their precise semantics, as well as the name of the function itself could be changed.

@sdrave sdrave added the pr:new-feature Introduces a new feature label Nov 20, 2023
@sdrave sdrave requested review from a team November 20, 2023 16:30
@sdrave sdrave added this to the 2024.1 milestone Feb 29, 2024
@sdrave sdrave self-assigned this Feb 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr:new-feature Introduces a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants