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

Print of the average update time #179

Open
wants to merge 1 commit into
base: unstable
Choose a base branch
from
Open

Conversation

ec147
Copy link

@ec147 ec147 commented Jul 29, 2024

  • Measurement of the average update time. This can be accessed with S.update_time at the end of the run.
  • Instead of being recomputed at each measure, the density matrix is now only computed when there is an update. When this is the case, the old density matrix is multiplied by the number of times it has been in the old configuration, and added to the measurement.

@Wentzell
Copy link
Member

Thank you @ec147 for this Pull Request!

Please add a description of the Feature and the changes to this PR.

Also, can you please adjust the git history to group the changes into
logical chunks with useful commit messages, instead of generic
messages like Update density_matrix.cpp

Update impurity_trace.cpp

Update density_matrix.cpp

Update density_matrix.hpp

Delete c++/triqs_cthyb/measures/update_time.hppZone.Identifier

Update update_time.hpp

Update double_remove.cpp

Update insert.cpp

Update remove.cpp

Update shift.cpp

Update qmc_data.hpp

Update solver_core.cpp

Update solver_core.cpp

Update solver_core.hpp

test

test2
@Wentzell
Copy link
Member

Can you motivate your changes?

With a proper setting of the length_cycle and n_cycles parameters one should encounter statistically independent, and in particular different, configurations each time that the density matrix is measured. So I am wondering if your commit isn't just working around an improper setting of these parameters.

@ec147
Copy link
Author

ec147 commented Oct 1, 2024

So I am wondering if your commit isn't just working around an improper setting of these parameters.

Sure, this is kinda what it is. The idea is simply to reduce the computation time for the users who simply want a quick calculation and do not necessarily want to go through the hassle of tuning length_cycle.

Of course, most of the time, one needs more than one update to fully decorrelate the configurations, and tuning length_cycle is necessary if you want the best performances. But even if you tune it, it might still be a possibility that at some point, you get stuck in a local minima for several cycles, and end up measuring the same configuration several times, which would be a waste.

Finally, printing the average update time gives a quick, reliable lower bound for the value of length_cycle.

This feature is not meant to revolutionize physics, but is simply there to improve the quality of life of the users. I am simply showing you all of my work here, feel free to pick whatever you think would be useful for the community.

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