Can mVMC be used to calculate the t-J model?

[LYZphy]

Dear mVMC developers,

The current mVMC provides two types of calculations: Hubbard-type and spin-type models. Can mVMC be used to calculate the t-J model?

Best regards.

[tmisawa]

I apologize for the delayed response. The tJ calculation feature has been implemented, and we plan to push it to a new branch shortly. Thank you for your patience.

[tmisawa]

Recently, we have implemented the tJ model in mVMC. For details, see #87 .

[LYZphy]

Dear Misawa,
Thank you for the timely updates to the t-J model implementation. To enable the t-J model calculations, is the correct procedure to replace the source files with those provided in Issue #87 and then recompile the project? Regarding the input file (modpara.def), does setting NExUpdatePath = 4 specifically activate the t-J model mode?

Best regards

[tmisawa]

@LYZphy

Thank you for your interest in the t-J model implementation.

1. Build procedure

Yes, your understanding is correct. You need to apply the changes from Issue #87 (commit 5b06975) to the mVMC source code and recompile.

2. NExUpdatePath settings for the t-J model

Two values are available for the t-J model:

• NExUpdatePath = 4: Performs SPINHOPPING updates only. An electron hops to a neighboring site, but the move is rejected if it would create double occupancy (enforcing the $U \to \infty$ constraint).

• NExUpdatePath = 5: Randomly alternates between EXCHANGE and SPINHOPPING updates with equal probability. This is recommended when exchange interactions are present in the Hamiltonian (e.g., Heisenberg or Kitaev terms), as it allows efficient sampling of both spin and charge degrees of freedom.

3. Important notes

• The no-double-occupancy constraint is enforced at three stages: initial configuration generation, Green's function evaluation, and post-move validation.
• BackFlow and Lanczos modes are not supported with the t-J model (NExUpdatePath = 4 or 5).

Best regards,
Takahiro Misawa

[tmisawa]

@LYZphy
Also, if you encounter any bugs or issues, please let us know.

[LYZphy]

Dear Misawa,
Recently, I performed some benchmarks of the $t-J$ model and the Hubbard model using mVMC, and encountered the following issue.
First, I set the number of samples per Markov chain to 4000, with the total number of samples being $N_c \times 4000$. Translational symmetry was used, and spin projection was not used.
I calculated the half-filled Hubbard model on a $Ns=16\times16$ square lattice with $Ne=256$ electrons, at $U/t=4$.
During the first 4000 SR steps, I performed two independent calculations with $N_{c1}=32$ and $N_{c2}=64$, respectively. At the end of 4000 steps, the energy had not yet converged. Therefore, I continued the calculation using the obtained 'zqp_opt.dat' file, but adjusted the parameters to $N_{c1}=64$ and $N_{c2}=128$. However, the energy then showed very large fluctuations, as shown in Fig.

benchmarkU4.pdf

What could be the cause of this behavior? The rest of my parameter settings are as follows:

Nsite 256
Ncond 256
2Sz 0
NSPGaussLeg 1
NSPStot 0
NMPTrans 4
NSROptItrStep 4000
NSROptItrSmp 100
DSROptRedCut 0.0010000000
DSROptStaDel 0.0200000000
DSROptStepDt 0.0200000000
NVMCWarmUp 10
NVMCInterval 1
NVMCSample 4000
NExUpdatePath 1
RndSeed 92374
NSplitSize 1
NStore 1
NSRCG 0

Best regards

[tmisawa]

@LYZphy

Thank you for the detailed information.

One possible cause is the restart file. In mVMC, zqp_opt.dat contains parameters averaged over the last NSROptItrSmp optimization steps.
In your case, NSROptItrSmp = 100, so zqp_opt.dat is not exactly the parameter set at the final SR step.

Could you compare the continuation runs using zqp_opt.dat and using the last line of zvo_var_001.dat as the restart parameters?
This will help check whether the averaging in zqp_opt.dat is responsible for the large fluctuations.

[LYZphy]

Dear Misawa,
Thanks for your advice. I extracted “zvo_var_001.dat” for the subsequent calculation. To save computational resources, I only optimized for 50 steps after the 4000th step. As a result, there were no longer large fluctuations. As shown in the figure, I have extracted the energy data from steps 3900 to 4050.
benchmark2.pdf
This issue was caused by setting NSROptItrSmp = 100. In future calculations, would it be acceptable to always set this parameter to 1?
I also have two additional questions:
(1)Based on my previous definition, if different sample numbers (Nc1, Nc2) give the same or very close energies, can that be considered as convergence of the calculation?
(2)When studying the Ising model, I learned about the critical slowing down effect, which is related to the update algorithm and the length of the Markov chain. For Hubbard and $t-J$ models, are there any studies on whether the warm-up steps and the Markov chain length must satisfy certain requirements?

[tmisawa]

@LYZphy

Thank you for checking this.

Setting NSROptItrSmp = 100 is not bad by itself. Rather, after the optimization has sufficiently converged, it is usually better to average over several final steps when calculating physical quantities, because this can reduce statistical fluctuations.

It is also acceptable to set NSROptItrSmp = 1, but please be careful when you use the resulting parameters for physical-quantity calculations. If the last optimization step still contains statistical noise, using only that single step may make the result less stable.

For question (1), judging the true convergence is a difficult problem. Even if different sample numbers, such as Nc1 and Nc2, lead to the same or very close energies, this does not guarantee that the state is the true global optimum. A safer approach is to perform calculations from several different initial conditions, and then discuss which state is likely to be the ground state within the range of mVMC calculations you performed.

For question (2), in VMC the Markov chain is used to sample configurations for evaluating expectation values of a given variational wave function. This is different from classical spin Monte Carlo simulations, where the Monte Carlo updates describe the sampling of the physical states themselves. Therefore, the critical slowing down issue is not exactly the same as in classical spin systems.

In practice, if the acceptance ratio is at least a few percent, the sampling is usually not problematic in VMC calculations. However, it is still safer to check the stability of the results by changing NVMCWarmUp, NVMCInterval, and NVMCSample, and by comparing independent runs when high accuracy is required.

Also, for future reference, if you have questions on a new topic, it would be helpful if you could open a new issue. This makes it easier to keep each discussion focused and easier for others to find later.