Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor interfaces built around alternating update #121
Refactor interfaces built around alternating update #121
Changes from 7 commits
ac76123
b23ab06
c2c5455
ed0df91
db524f7
d258ccc
6ff116a
0ac2f2d
c02662c
1a8ff33
80620b8
4c33d65
114ef3e
b817587
723fae9
1e40a79
5587391
0620943
7865f81
e08ba96
30455a4
86dd746
59f45c1
8bc62fb
ac1a923
2748927
1fe92b3
9e8e635
23cc545
3d5ade8
64ef223
812de92
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think
region_update_kwargs
sounds better to me.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though the same discussion on
exponentiate_updater
applies here, I think we should discuss how these are being passed and maybe merge them withupdater_kwargs
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this will be obsolete soon, I am in favor of sticking with
region_kwargs
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the plan to combine these into
updater_kwargs
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updater_kwargs
areupdater
specific kwargs, whileregion_args
are among the things that we expose to all updaters. in principle, we can nest the region_args into updater_kwargs in the call toregion_update
but I am not sure if that's preferable.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm ok, I just have found it hard to keep track of the logic of why certain keyword arguments are bundled in certain ways, how they will be used, etc.
For example, from the perspective of this function, the only argument I can see that is being used here from
region_kwargs
istime_step
, which I don't think is really any different conceptually from the arguments being passed inupdater_kwargs
(it's just another thing being used by the solver/updater). So it makes sense to me to just bundle those together in one flatNamedTuple
calledupdater_kwargs
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed, these will eventually be bundled together in an upcoming PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so we remember what
2
andInf
mean.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I'm not sure how I feel about calling this
dmrg_sweep
since it could be used by other solvers likelinsolve
. I'm also not a huge fan of the function nametdvp_sweep
for the same reason.Maybe we can rethink this API a bit, for example rename the current
tdvp_sweep
todefault_sweep_plan
and then just call that with different inputs from within the different solvers. I think a good design for that would be to choose default values that "just work" for DMRG, including defaulting toorder=2
, and then provide optional inputs likereverse_step=true
andtime_step
for use with TDVP. That may mean moving some of the inputs like order and time step to keyword arguments, which seems like a better design anyway.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, and this is what the
default_sweep_regions
function was trying to be. That is, a sort of "typical" sweep plan that most algorithms (dmrg, linsolve, etc.) could use. We could definitely think about moving that function out of theupdate_step.jl
file but the intent there was for it to be a pretty generic default.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, I forgot about
default_sweep_regions
, I'm not sure what the fate of that is in the current PR since a lot of things are getting changed in this PR. But it seems likedefault_sweep_regions
,tdvp_sweep
, anddmrg_sweep
should all get consolidated into a single function, which tentatively we are thinking of calling something likedefault_sweep_plan
,default_region_updates
, ordefault_region_update_plans
(since it contains both the regions that will be updated but also information about how to do the update), which I think should just get called directly by the different solvers likedmrg
,tdvp
,linsolve
, etc. and passed toalternating_update
.Opinions on what to name that function would be welcome. We want to come up with a good name for that function and what it outputs which we can then use consistently throughout the rest of the code. The list output by
tdvp_sweep
/dmrg_sweep
is calledregion_updates
in the current version of this PR but we are discussing alternative names, which hopefully will be consistent with the name of the new function.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I incorporated the suggestion, and the sweep_regions constructor is planend to be refactored in an upcoming PR