-
Notifications
You must be signed in to change notification settings - Fork 12
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
Implement symmetric versions of models #66
Conversation
Codecov ReportAttention: Patch coverage is
|
I noticed a problem with the symmetrized optimization when I looked at Lander's symmetrization code I hadn't taken into account before: already at the Of course it is not very nice to have |
The models now overload/mimic the |
I think the warnings are because you defined the lattice to default to the peps models, while they already had default values to be the infinitechain. Probably it's better to just not give them a default value here. |
Whoops, I didn't have that in mind but I'm also okay with having to specify
The problem with just having the symmetrization kwarg is that we still need a callback/finalize kwarg (for example if one wants to implement some kind of checkpoint saving mechanism). I do of course agree that At this point the optimization interface with all the arguments has grown too much and I think we should consider doing a clean rewrite. Also if we switch to Optim.jl/Manopt.jl then things will again change a bit (i.e. how to implement callbacks and the symmetrization). So I'm not sure what the best way is to proceed in the meantime. I could implement a symmetrization kwarg which accepts |
I think it's definitely nicer to have a symmetrize and finalize kwarg in that case. I think you could wrap the user-provided finalizer by first doing the symmetrization and then the finalizer, and at least this is hiding the fact that you need to know about retractions and inner products etc that have to be compatible. My general feeling is a bit like this: either we try and do things automatically, in which case it should be possible to use the interface without knowing too much about the internals, or we consider this to be an expert usage case. If the former, I think symmetrize is a bit more intuitive, and if the latter, it's not actually that hard to hijack the optimization routine yourself to hack in custom finalizers etc. I don't like mixing up these two concepts, as that typically ends up with being too elaborate for casual use, while not being flexible if you want to really fiddle with it |
I would also think so, I'll get to it after the weekend!
I definitely agree with the general idea. I feel like that we already are somewhat in the middle ground between an expert and automatic user interface, so that's why I would like to redesign a bit at some point (especially the way all the parameters are set). But for now I will just implement the symmetrization kwarg. |
In this PR we add symmetric model Hamiltonians using MPSKitModels.jl. This allows us to run, e.g., a$\mathrm{U}(1)$ symmetric optimization of the Heisenberg model.