Pass through more settings for environment and gauging sub-algorithms

[leburgel]

An attempt to add more control over the VUMPS/VOMPS subroutines.

Previously, only the tol of the environment algorithm was ever actually passed through to the environment solver in the ends, and there was no way to switch the orthogonalization method from the default value (QR-based orthogonalization. Here I tried to address that passing all of the kwargs in the environment_alg down to the solver, and adding the orthogonalization algorithm to the gauging algorithm and passing that down accordingly.

[codecov]

Codecov Report

❌ Patch coverage is 85.00000% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/algorithms/approximate/vomps.jl	66.66%	2 Missing ⚠️
src/algorithms/statmech/vomps.jl	83.33%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/algorithms/groundstate/vumps.jl	81.31% <100.00%> (+0.20%)	⬆️
src/environments/abstract_envs.jl	93.47% <ø> (ø)
src/utility/defaults.jl	100.00% <100.00%> (ø)
src/algorithms/statmech/vomps.jl	80.95% <83.33%> (+0.30%)	⬆️
src/algorithms/approximate/vomps.jl	66.15% <66.66%> (-0.52%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lkdvos]

Looks like a great addition, thanks!

I had always wanted to have a better way of dealing with the environment algorithms, but I think the annoying part is the distinction between the linear solver for hamiltonians and the eigensolver for MPOs. There might be a case to be made to replace the NamedTuple arguments with actual KrylovKit algorithms from the start too, although I guess that requires slightly more work?

[leburgel]

There might be a case to be made to replace the NamedTuple arguments with actual KrylovKit algorithms from the start too, although I guess that requires slightly more work?

We could put in some algorithm selection logic similar to MatrixAlgebraKit, but I guess this would best be handled in KrylovKit itself instead of handling it here. I don't think working with actual KrylovKit algorithms from the start would be that easy, in particular for the environment alggorithms. These are instantiated when calling e.g. VUMPS(...), at which point there's no way to know about the type of the MPO that determines what kind of algorithm you actually need. So unless we make one choice and then convert to a different kind of solver when it's needed by copying all of the settings, I don't think it's more convenient to directly work with KrylovKit algorithms.

I'm personally fine with the NamedTuple arguments. I think at this point the two remaining problems are that:

• There's no way to select the linsolve algorithm type itself, say if we would want to use BiCGStab instead of GMRES. But I don't know if this ever makes a real difference.
• The linsolve and eigsolve algorithms don't take all the same keywords (in particular the latter has an eager setting while the former does not). So in order to always pass everything I had to allow the kwargs for the linsolve environment_alg to "overflow" and ignore anything unused. Not sure if this is very good practice.