Major refactoring of the codebase. #92
Conversation
…thonormality checks where appropriate.
There was a problem hiding this comment.
It looks pretty good to me. The only concern I have is about the orthogonalize_vector_against_basis and its extension. I feel like these should actually implement a proper two-pass modified Gram-Schmit process. We wouldn't be re-using the innerprod function, but at least the implementation will be numerically stable for sure. Moreover, it would enable us to get rid of the second passes in all the functions which rely on Gram-Schmidt (e.g. qr, gmres, update_hessenberg, etc.)
…ize_against_basis and for double_gram_schmidt_step.
Added double_gram_schmidt_step and deployed it with logging.
Replaces update_hessenberg_matrix.
Added optional orthonormality check in orthogonalize_against_basis.
Set this check to false in all performance-critical routines in the core.
IterativeSolvers.f90:
Deployed double_gram_schmidt_step.
Deployed orthonormalize_against_basis.
I haven't checked in on the community recently, but I remember there being some controversy regarding the stability of MGS for some fringe cases and some people even advocating for triple GS ... In any case, MGS is more expensive than DGS, while the latter usually does the trick as well in my experience. I've now gone with DGS, which is a wrapper and makes the orthogonalization fairly clean throughout the code. |
innerprod, deployed throughoutorthogonalize_against_basis, deployed throughout the toolbox.one_*/zero_*->LightKrylov_Constants