Use Observer for output

[emstoudenmire]

This PR moves the task of printing output into helper functions which are put into Observers, either the step_observer! or the sweep_observer!. The tdvp function now takes advantage of this design to inject another function that prints the current time reached after each sweep.

Some other changes include:

• calling update!(step_observer!,...) from inside local_update to avoid returning too many variables from local_update (which makes me wonder if local_update should just be inlined back into update_step?)
• changed the "info" returned by solvers to be a NamedTuple. This seems more flexible and useful to me than solvers returning a sort of ad hoc set of values or their own custom info type. For one thing, it helps with generic code because then the info return value can be splatted into the call to update! so that the observer can have access to it.
• [Minor change:] renamed update_sweep to default_sweep_regions
• [Minor change:] the outputlevel >= 2 step printing prints the region rather than attempting to print a site or bond, which would be less generic

[codecov-commenter]

Codecov Report

Merging #93 (41cc5d1) into main (34fd5dc) will decrease coverage by 0.05%.
The diff coverage is 62.31%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@            Coverage Diff             @@
##             main      #93      +/-   ##
==========================================
- Coverage   79.25%   79.20%   -0.05%     
==========================================
  Files          61       61              
  Lines        3442     3458      +16     
==========================================
+ Hits         2728     2739      +11     
- Misses        714      719       +5     

Impacted Files	Coverage Δ
src/ITensorNetworks.jl	77.77% <ø> (ø)
src/treetensornetworks/solvers/linsolve.jl	60.00% <ø> (ø)
src/treetensornetworks/solvers/update_step.jl	82.85% <50.00%> (-3.91%)	⬇️
src/treetensornetworks/solvers/tdvp.jl	68.25% <62.06%> (-4.09%)	⬇️
...c/treetensornetworks/solvers/alternating_update.jl	86.53% <73.33%> (+5.05%)	⬆️
src/treetensornetworks/solvers/contract.jl	91.30% <100.00%> (ø)
src/treetensornetworks/solvers/dmrg.jl	100.00% <100.00%> (ø)
src/treetensornetworks/solvers/dmrg_x.jl	100.00% <100.00%> (ø)

... and 4 files with indirect coverage changes

[emstoudenmire]

Tests are passing, except for code coverage. (Can fix but it's a bit stringent when making large changes to the code.)

[mtfishman]

Looks good, thanks!

I think it makes sense to keep local_update separate, I could imagine making that fully customizable in the future (i.e. letting people pass their own local_update function).

[emstoudenmire]

Good point regarding local_update. Let's leave it for now, even though the args passing back and forth there is a bit awkward at the moment.

A good test case might be TCI when that goes in: there the solver can be simply overloaded, but the factorize step has to be customized to use the LDU method and return pivot information etc. I could envision doing this by completely overloading local_update though in that example it's probably calling for a more narrow customization like a keyword arg to factorize or a more generic callback that replaces factorize. So perhaps a full overload of local_update would be for some even more complicated/different algorithm that we aren't envisioning yet.

[mtfishman]

Yeah, I agree that we also want to more narrowly be able to customize the factorize step, since that could be quite different for general region updates on trees (where the tools that @LinjianMa is developing for factorizing a network into a TTN will be helpful) or updating regions of general tensor networks, especially if we want to account for different gauges (like isometric gauges vs. the Vidal gauge).

[emstoudenmire]

Agreed. I can use the upcoming PR to add TCI to also come up with a good scheme for customizing the factorize step. Right now I'm thinking I'll wait until the Waintal group's paper is out before adding it, though, since it borrows heavily from their ideas (with their permission) and I don't want to front-run them. I think it will be out in a month or so.

…

On Tue, 11 Jul 2023 at 12:22, Matt Fishman ***@***.***> wrote: Yeah, I agree that we also want to more narrowly be able to customize the factorize step, since that could be quite different for general region updates on trees (where the tools that @LinjianMa <https://github.com/LinjianMa> is developing for factorizing a network into a TTN will be helpful) or updating regions of general tensor networks, especially if we want to account for different gauges (like isometric gauges vs. the Vidal gauge). — Reply to this email directly, view it on GitHub <#93 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHJ3ROJKME544HSGCVIOMTXPV4UPANCNFSM6AAAAAAZRS3JHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- -=Miles Stoudenmire=- ***@***.*** ***@***.*** http://itensor.org/miles/