Proposal of updates with Langevin equation

[ALF-Import-Bot]

In GitLab by @agoetz on Jan 15, 2025, 15:13 UTC:

Migrated from GitLab: https://git.physik.uni-wuerzburg.de/ALF/ALF/-/issues/305

[ALF-Import-Bot]

In GitLab by @agoetz on Jan 15, 2025, 15:13 UTC:

created branch 305-proposal-of-updates-with-langevin-equation to address this issue

[ALF-Import-Bot]

In GitLab by @fassaad on Jan 29, 2025, 15:43 UTC:

The aim here is to use Langevin as a proposal move. As it stands, this would work to replace local updates of a continuous field. Anika will upload some of the benchmarks that she has carried out. There are many questions that would be nice to discuss.

1. It is possible to use this for updating a selection of fields on a single time slice. i.e. Global tau
2. It is also possible to use it to update an arbitrary set of space time fields. i.e. Global moves

In this way we would be able to provide a default set of global in the ALF. The question is how to program elegantly all this? Anika will upload a version, and it would be great is some of you could take a look. At one point it would be good to merge this in the Master Branch.

Thanks Anika for all the work!

[ALF-Import-Bot]

In GitLab by @agoetz on Jan 30, 2025, 14:08 UTC:

undefined

Here are some benchmark data. I compared the results for the Hubbard model on a six-site chain with $U=4$ and $\beta=5$ with the default updating scheme for both the discrete and continuous HS and exact diagonalization. Here, $\delta t_l$ is the Langevin time step.

[ALF-Import-Bot]

In GitLab by @agoetz on Apr 25, 2025, 14:40 UTC:

I pushed all possible updating scheme: 1) local, 2) local in time and 3) global. It's just a draft version, since I'm not sure about the embedding.

For example in the 3) global case, I decided to use the structure of the Langevin_HMC_mod.F90 file. So far we have two options: Langevin and HMC. I have included a third option MALA (Metropolis-adjusted Langevin algorithm). Langevin will override both HMC and MALA if more than one is set to .true., but how do we handle the case HMC=.true. .and. MALA=.true.? In principle, one could combine these two updating schemes.

[ALF-Import-Bot]

In GitLab by @agoetz on Apr 30, 2025, 13:28 UTC:

Todo list:

• c_memcpy -> Maybe we should do this in a separate branch, as this is not specific to the Langevin proposal. For example, in the Global_tau update, the Green function is also copied at the beginning of the update.

• Single S0 instead of the whole thing

• Same format for global_tau and global_langevin_tau

• Override functions Include N_Global_Langevin_tau

• Nt_sequential_start and Nt_sequential_end (We cannot completely skip the sequential part!) Try to change. -> It should be possible to skip the sequential part by setting Nt_sequential_start=1 and Nt_sequential_end=0, if I'm not missing something. There will be a warning Warning: Nt_sequential_end is smaller than Nt_sequential_start, but the code still runs.

• Choice of the fields in the Global_MALA

• Documentation. Can we produce a table of all possible update schemes. And what is compatible with what. MALA, HMC, Single spin flip, parallel tempering and Global and Global tau can all be combined, in principle. Langevin stands alone. We should check that this really works. Could you please upload the plot in Documentation/Figures/MALA

• Does this branch break backward compatibility? Yes it does due to global tau overriding function.

[ALF-Import-Bot]

In GitLab by @joaogci on May 5, 2025, 08:26 UTC:

Actually, I further tested the memcpy issue. It is indeed faster than the matrix copy from fortran, but if you compile with -O3, then the built-in fortran matrix copy is faster.

[ALF-Import-Bot]

In GitLab by @fassaad on May 7, 2025, 10:47 UTC:

Since the default gnu compiler options use -O3 we will just skip this.

[ALF-Import-Bot]

In GitLab by @fassaad on May 9, 2025, 14:51 UTC:

We can indeed omit sequential updates. It just gives a warning and runs. Question do we want to eliminate this warning?