ITensor / ITensor/ITensorMPS.jl
[ITensors] [ENHANCEMENT] Expose `ConvergenceInfo` in calls to KrylovKit methods
Nobody has claimed this yet.
- Dominant language
- Julia
- Stars
- 85
- Forks
- 27
- Avg merge
- 22m
- Merged PRs (30d)
- 1
Description
I'm be curious what others think of the value of the following. I was recently trying to debug some issues I was having with linsolve via ITensorTDVP (which I understand will be deprecated by ITensorMPS). linsolve is built on top of KrylovKits methods and in this particular case their implementation of GMRES.
Underlying this all, there is a series of iterations which are trying to minimize a cost function (usually the square of the L2 norm of some residual vector, for linsolve its the cost function formed by doing two-site overlapping updates up the MPS chain). I found myself wondering how I could see this residual or "cost" for each iteration of the GMRES call. I don't think it is currently exposed in ITensors. I know with outputlevel you can see the maxtruncerr but I don't think that is the same as the residual or cost from GMRES. If I have that wrong please set me straight. From KrylovKit's documentation, the residual information is contained in a struct called ConvergenceInfo.
Starting from my specific use case of linsolve here is what I found:
linsolvecallsalternating_updatealternating_updatecallssweep_updatesweep_updatecallssub_sweep_update
Within sub_sweep_update there is a call to region_update! which does appear to return ConvergenceInfo from KyrlovKit as info (see line 117 of sweep_update.jl). However, it never makes it outside the call to sweep_update. So it would be a matter of propagating info back up the chain of return values. Probably some type of container would need to be created to hold the ConvergenceInfo for each call to region_update!. This could be done with a NamedTuple or maybe something more complex if its warranted.
Thoughts on this?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at linsolve and follow the documented call chain through alternating_update, sweep_update, sub_sweep_update, and region_update!. Inspect sweep_update.jl around line 117, where ConvergenceInfo is returned as info, then trace how return values are propagated. Done means callers of linsolve can access the ConvergenceInfo from the relevant region_update! calls.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia
- Domain
- backend-api-design
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100