Skip to content

Conversation

@corbett5
Copy link

@corbett5 corbett5 changed the title Moved over from ITensors. Real valued non-Hermitian DMRG Dec 23, 2024
@corbett5
Copy link
Author

@mtfishman If I resolve the merge conflicts can this be merged?

@mtfishman
Copy link
Member

mtfishman commented Dec 9, 2025

@mtfishman If I resolve the merge conflicts can this be merged?

I think it seems reasonable to have this kind of functionality, though I'm starting to worry about putting too much functionality and too many keyword arguments into the dmrg function.

I think a design I would prefer would be to rename the current dmrg(args...; kwargs...) function to generic_dmrg(f, args...; kwargs...), where the first argument f is a function that is called for the local update, so for dmrg it would be a function that calls eigsolve. Then, we could define realdmrg where f is a function that calls realeigsolve.

For some context, providing flexibility for different local solver backends (in this case, eigsolve vs. realeigsolve) is one of the motivations behind alternating_update function in this package along with the next-generation "sweep solving" framework we're developing in ITensorNetworks.jl, where the design allows for specifying a custom local update function along with other customizability (like changing the number of sites that will be updated, the order of updating the sites, how the gauge center is moved, etc.).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants