ITensor / ITensor/ITensorMPS.jl

[ITensors] [ENHANCEMENT] Expose `ConvergenceInfo` in calls to KrylovKit methods

Open
#88 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
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:

  • linsolve calls alternating_update
  • alternating_update calls sweep_update
  • sweep_update calls sub_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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.