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 81.29032% with 29 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...c/algorithms/excitation/quasiparticleexcitation.jl	41.66%	7 Missing ⚠️
src/environments/abstract_envs.jl	40.00%	3 Missing ⚠️
src/environments/multiline_envs.jl	76.92%	3 Missing ⚠️
src/algorithms/approximate/fvomps.jl	0.00%	2 Missing ⚠️
src/algorithms/approximate/vomps.jl	66.66%	2 Missing ⚠️
src/algorithms/statmech/leading_boundary.jl	75.00%	2 Missing ⚠️
src/algorithms/statmech/vomps.jl	75.00%	2 Missing ⚠️
src/environments/qp_envs.jl	77.77%	2 Missing ⚠️
src/algorithms/changebonds/randexpand.jl	0.00%	1 Missing ⚠️
src/algorithms/timestep/tdvp.jl	50.00%	1 Missing ⚠️
... and 4 more

Files with missing lines	Coverage Δ
src/MPSKit.jl	100.00% <ø> (ø)
src/algorithms/ED.jl	100.00% <100.00%> (ø)
src/algorithms/approximate/approximate.jl	100.00% <100.00%> (ø)
src/algorithms/approximate/idmrg.jl	96.72% <ø> (ø)
src/algorithms/changebonds/optimalexpand.jl	100.00% <100.00%> (ø)
src/algorithms/changebonds/svdcut.jl	89.18% <100.00%> (ø)
src/algorithms/changebonds/vumpssvd.jl	100.00% <100.00%> (ø)
src/algorithms/excitation/chepigaansatz.jl	91.48% <ø> (ø)
src/algorithms/excitation/dmrgexcitation.jl	100.00% <100.00%> (ø)
src/algorithms/expval.jl	88.23% <ø> (ø)
... and 29 more

🚀 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.

[lkdvos]

I slightly reworked the approach by making use of DefaultAlgorithm instead - the idea being that I delay creating the correct algorithm, but if you want you could actually create an algorithm from the start. I think that means you could use BiCGStab if you wanted, at least it gives the option to check if it makes a difference 😉 .

I might still have to debug slightly,, but I think the idea at least makes sense

[lkdvos]

I promise I know what I'm doing...

[lkdvos]

@leburgel sorry for taking a while to get this fixed, somehow this was more painful than I wanted. I now should have figured everything out to be consistent, which might be slightly more verbose but at least it is clear what is supposed to go where.
If you can have a look, feel free to merge if you are happy with this!

In any case, this probably counts as a breaking change, which I will slot in with the other (minor) breaking changes in some of the other PRs that I want to finish this and next week, and then just release another minor version.