Document interface of library#346
Conversation
…recated will be considered internal.)
|
Your PR no longer requires formatting changes. Thank you for your contribution! |
| ## TreeTensorNetwork Constructors | ||
|
|
||
| * From `Op` and related types (`opsum_to_ttn.jl`): | ||
| ```julia | ||
| mpo(os::OpSum, external_inds::Vector; kws...) | ||
| mpo(os::OpSum, s::IndsNetwork; kws...) | ||
| ttn(o::Op, s::IndsNetwork; kws...) | ||
| ttn(o::Scaled{C, Op}, s::IndsNetwork; kws...) | ||
| ttn(o::Sum{Op}, s::IndsNetwork; kws...) | ||
| ttn(o::Prod{Op}, s::IndsNetwork; kws...) | ||
| ttn(o::Scaled{C, Prod{Op}}, s::IndsNetwork; kws...) | ||
| ttn(o::Sum{Scaled{C, Op}}, s::IndsNetwork; kws...) | ||
| ``` |
There was a problem hiding this comment.
I guess we'll have to think about the alternatives to these if we remove them. Maybe it would be something like ttn(opsum::OpSum, graph::NamedGraph, siteinds:Dict{V, <: Index}), i.e. you specify the graph and site indices? Though I guess we could make it more general, i.e. ITensorNetwork(opsum::OpSum, graph::NamedGraph, siteinds:Dict{V, <: Index}), and error if the graph isn't a tree.
There was a problem hiding this comment.
It was my bad to include the mpo ones here. I had put them in "interface" actually, just accidentally duplicated them here.
Were your comments above about a more general constructor that would take the place of the mpo ones?
The ones really intended to be here in Deprecated are the ones which take other Op-adjacent data like Scaled{C,Op}, Prod{Op}, etc. My guess was we might want those but later on through Lukas's system so maybe better not to have them here? They are little one-liners though so not causing any big issues. What do you think of these?
There was a problem hiding this comment.
I see, I thought you were including all mpo and ttn constructors. That sounds reasonable to get rid of Scaled{C,Op}, Prod{Op}, etc. for now (non-OpSum ones).
I was indeed suggesting getting rid of ttn and mpo entirely and just focusing on a more general ITensorNetwork constructor that just restricts to trees with a runtime check.
There was a problem hiding this comment.
Of course, that would be a longer term change which assumes we are getting rid of the TTN type, and since the current DMRG/TDVP code still expects a TTN then we could replace mpo and ttn with using the TTN type directly, i.e. remove mpo and ttn functions in favor of just making a TTN constructor that accepts an OpSum.
There was a problem hiding this comment.
I think the above would be a good plan. One way we could go would be to start replacing tree tensor network methods with ITensorNetwork ones (just restricted to trees with a runtime check) and then after some rounds of this see how much of a "footprint" is left by the actual TreeTensorNetwork type. It might not be that much after a handful of key changes.
My guess is probably the largest footprint is through parts of the code, like solvers, which rely on the gauging capabilities of tree tensor networks but also of course that's something that could be switched over to ITensorNetworks with a runtime tree check. Also I remember you had some thoughts about gauging and caches that sounded more deep.. we should discuss more.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #346 +/- ##
==========================================
- Coverage 73.08% 71.10% -1.99%
==========================================
Files 66 64 -2
Lines 3151 3097 -54
==========================================
- Hits 2303 2202 -101
- Misses 848 895 +47
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@emstoudenmire can you bump the version, fix the docs build, and format just so we can get tests passing? Also, I noticed you are just including the function signatures in the docs. For functions that have docstrings, can you insert the docstring instead of just putting the function signature? |
3 participants
This PR adds documentation of which methods we may consider "interface", and thus should keep and add docstrings for, versus deprecated methods we may want to delete. Methods not in the two files
interface_methods.mdanddeprecated_methods.mdare considered internal, developer-facing methods.