Convergence of the parameter length_cycle

[LeoGaspard]

Dear TRIQS developpers,

I recently posted about an issue I had about the auto-correlation time and you suggested the tutorial on the unstable branch about how to chose the parameters for the DMFT calculation.

I followed this tutorial for a calculation that I am trying to do, and similarly to the tutorial I found a nice decreasing curve for the convergence of length_cycle :

I then decided to chose a value for length cycle and launched the calculation, but what happened was that the auto-correlation time changed drastically after some iterations, due to the updated self-energy :

I figured that maybe the parameter shoud be chosen at each iteration, and changed the code so that it always choses a value such that the auto-correlation time is "acceptable", this is what I get :

Which seems better. However, this is very expensive as the only way to decide if the auto-correlation time is to already perform a complete iteration. And as the auto-correlation time needed to be high in the end of the calculation (cf next figure), I needed to perform in total 99 iteration that were only used to adjust the parameter length_cycle during the calculation.

My question is the following : is it necessary to converge the parameter length_cycle at each iteration, and if so, do you think that there would be a way that would waste less ressources than doing the full calculation for each trial value ?

Best regards,
Léo Gaspard

[the-hampel]

Hi @LeoGaspard,
sorry for the slow response. Yes I also already thought about having an automatic option for this. Indeed it would be best to adjust auto_corr_time in a way that it works for the converged calculation, or at each DMFT step. Since setting length_cycle on the smaller site only induces sampling overhead which is effectively filtered when binning G(tau), I would recommend setting length_cycle to a too small number. However, in cases in which the measurement of the observables takes a long time it can be crucial to find an optimal value. There are currently two routes that seem to be feasible:

1. in an iterative DMFT calculation use auto_corr_time from the previous DMFT iteration as a guess for the next DMFT iteration.
2. use an automatic algorithm within cthyb. We are currently exploring this option by allowing to measure auto_corr_time during the warmup of the solver and adjust automatically, or at least report it in a first version. If I understand your ansatz correct you are doing exactly this by manually running the solve comand multiple times right?

Be also advised that the auto_corr_time is a single number, reporting the upper bound of correlation time. It is not an anverage, i.e. if you have multiple orbitals it could of course be that certain components of G(tau) de-correlate faster than others. In this case it might be still advantageous to choose a lengt_cycle that measures more often to sample more of the components that already de-correlated.

Maybe you can try if option 1 might be also a viable option for you at this point. This would not require to run cthyb multiple times per DMFT iteration.

[LeoGaspard]

Hi @the-hampel ,
Thank you for your explanation. Indeed what I do is use the length_cycle of the previous iteration as a guess, and run Solve repeatedly until I am satisfied with the auto-correlation time that the solver outputs (in my case I wanted it to be between 0.6 and 1.4).

The problem is that the "correct" length_cycle parameters may vary a lot between the iterations, in a way that I am not fully sure I understand.
It seems that when an iteration finds a solution that brings the system to a more correlated phase, the auto-correlation time becomes very large, and suddenly becomes very small at the next iteration. If the problem is that the sampling is harder in a more correlated phase, requiring more steps to de-correlate G(tau), I would have expected that the auto-correlation time would stay high after this critical iteration, but it is not the case.

[the-hampel]

If you look at the self-energy in the iteration where you observe the large change in auto_corr_time, is this maybe just very close to a phase transition? While you converge the Weiss-field it could be that one of your DMFT steps is very close to a transition. In those cases the auto_corr_time could maybe suddenly change drastically?

Again just as a reminder as long as your length-cycle is shorter than ideal and not longer you should not have any sampling problems, only measurement overhead.