Skip to content
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

Change the default time evolution method #143

Open
liwt31 opened this issue Oct 21, 2022 · 5 comments
Open

Change the default time evolution method #143

liwt31 opened this issue Oct 21, 2022 · 5 comments

Comments

@liwt31
Copy link
Collaborator

liwt31 commented Oct 21, 2022

Currently, the default time evolution method is prop_and_compress, which is not very popular. Maybe it's time to change it to TDVP_PS or TDVP_VMF?

@jjren
Copy link
Collaborator

jjren commented Oct 22, 2022

RK4 is actually more black box than TDVP_PS and TDVP_VMF to get not bad results (of course not the best) for most Hamiltonians.
Because TDVP methods need a good/correct initialization (renormalized space expansion) to avoid the evolution stuck in a wrong subspace. It depends on if the user understands and runs the algorithm correctly.
For example, in the transport problem, all the one-exciton state should be included in the initial renormalized space carefully.
If not, you will get an artificial localization solution.
I don't know whether 2-site TDVP_PS can avoid this kind of problem. But RK4 is more robust, at least get a "correct" answer.
Do you think so?

@liwt31
Copy link
Collaborator Author

liwt31 commented Oct 24, 2022

Makes sense. However I'd like to add that the step control in TDVP_VMF is a unique advantage.

Then it again boils down to the documentation. We should list all the possible schemes and their (dis)advantages. Some of them are published with well-supported data (like the 2020JCP work). Some of them are more empirical.

@jjren
Copy link
Collaborator

jjren commented Oct 24, 2022

I totally agree with you about improving the documentation for all the evolution algorithms.
It is better if you can write a template and set a doc structure, then I can add content.

For the current situation, I think we can switch the default algorithm to P&C TD RK (general explicit RK propagator for both time-dependent/independent H), with which the time-step can be controlled adaptively (e.g Cash-Karp45, RKF45).

@liwt31
Copy link
Collaborator Author

liwt31 commented Oct 24, 2022

I don't know whether 2-site TDVP_PS can avoid this kind of problem.

I think not if the electronic sites are separated by phonon sites. Maybe this is worth documenting too.

It is better if you can write a template and set a doc structure, then I can add content.

No problem

we can switch the default algorithm to P&C TD RK

OK. Could you do it while adding the documentation? I assume you're more familiar with the setup. Honestly I rarely use this method and I'm under the impression that the step-size control for P&C RKF is not particularly reliable. Sometimes the step size simply keeps shrinking to infinitely small in one step.

@jjren
Copy link
Collaborator

jjren commented Oct 24, 2022

OK. Could you do it while adding the documentation? I assume you're more familiar with the setup. Honestly I rarely use this method and I'm under the impression that the step-size control for P&C RKF is not particularly reliable. Sometimes the step size simply keeps shrinking to infinitely small in one step.

That's true in some cases because the error due to time-step is probably overwhelmed by the truncation error in one single step. In this case, weird results will occur.
In my experience, one simple prescription is that RK45 should be used in combination with adaptive bond dimension ($\eta_bond dimension cutoff < \eta_{time step error}$).
I will switch the current scheme to this evolution scheme, make some tests, and add documentation.

@liwt31 liwt31 mentioned this issue Oct 26, 2022
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

No branches or pull requests

2 participants