Strange L Dependence at U=0 for a Depleted Square Geometry

[GoogleCodeExporter]

This concerns QUEST 1.4. You may be able to tell me if 1.4.4 has the same 
"issue" too.

At U=0, when using a geometry file that corresponds to the 1/5-depleted square 
lattice, at least the time-independent results seem to depend on the number of 
time slices, L.

This is not quite the case for the simple square lattice geometry. For the 
latter, I only get unphysical results if, e.g., L=1 and \Delta\tau=1. The 
attached input files for the square geometry (with L>1) produce the same 
test.out, whereas the ones for the depleted lattice yield different (wrong) 
outputs.

The above observation does not depend on whether -DDQMC_ASQRD or -D_CKB flag is 
used in compilation, or the value for nwrap.

I have kept the parameters of the input files to the minimum (maybe too 
minimalistic!).

I do not get any errors in either case, just the usual initialization warnings.

The results for L=1 and \Deta\tau=1 are obviously wrong as the density is not 1 
in the output (\mu=0 and both lattices are bipartite!). This is one issue. But, 
the real issue is that, for the depleted lattice, the results of L=10 and 
\Delta\tau=0.1 will continue to change [improve(?)] (except the density, of 
course) by increasing L, say if I choose L=100 and \Delta\tau=0.01.

Any idea what is happening?

Thanks,
Ehsan

Original issue reported on code.google.com by ehsankha...@gmail.com on 17 Apr 2014 at 12:31

Attachments:

• in_Square_L1_dtau1
• in_Square_L10_dtau0.1
• test.out_Square_L1_dtau1
• test.out_Square_L10_dtau0.1
• in_Depleted_L1_dtau1
• in_Depleted_L10_dtau0.1
• in_Depleted_L100_dtau0.01
• test.out_Depleted_L1_dtau1
• test.out_Depleted_L10_dtau0.1
• test.out_Depleted_L100_dtau0.01
• square.geom
• one5th-deplt-4x4.geom
• in_Square_L100_dtau0.01
• test.out_Square_L100_dtau0.01

[GoogleCodeExporter]

[1] QUEST assumes periodic boundary condition in imaginary-time axis. Setting 
L=1 sort of looses 
the 'direction' in time so I think L=1 unphysical results are probably caused 
by this reason.

[2] U=0 results are exact when using dense matrix multiplication. However, 
using checkerboard 
decomposition would induce an O(tau^2) error to the data. I ran 4 tests with 
the supplied 1/5-depleted 
lattice geometry file. The first line is the exact kinetic energy computed 
using dense matrix method. 
The rest are kinetic energies obtained using the CKB method with different dtau 
values. As can be seen,
as dtau gets smaller, the CKB result is getting closer to the exact one.

dense             Kinetic energy :  -0.10652812E+01 +-  0.00000000E+00

L10               Kinetic energy :  -0.10655892E+01 +-  0.00000000E+00
L100              Kinetic energy :  -0.10652843E+01 +-  0.00000000E+00
L1000             Kinetic energy :  -0.10652812E+01 +-  0.00000000E+00

[3] What confuses me is that on a square lattice, CKB and dense matrix produce 
exactly the same
results. I also tested triangular lattices, and reach the same conclusion. I'm 
not sure what's going 
on at the moment. I'll report back when I have progress.

Original comment by cxc639 on 6 Aug 2014 at 7:36

Attachments:

• test.out_one5th_CKB_L10_dtau0.1
• test.out_one5th_CKB_L100_dtau0.01
• test.out_one5th_CKB_L1000_dtau0.001
• test.out_one5th_denseB_L100_dtau0.01

[GoogleCodeExporter]

About [1]

I think QUEST should throw some meaningful error when someone tries to use L = 
1.

Original comment by iglovi...@gmail.com on 6 Aug 2014 at 7:43

[GoogleCodeExporter]

It is correct that checkerboard has Trotter corrections at U=0
because Kx and Ky do not commute.  We should not worry about them,
except at U=0 where we need to be aware, because as long as U>t
the Trotter errors from K not commuting with P dominate
the CKB Trotter errors.

Another point:  There are some special cases where Kx and Ky
'accidentally' commute.  For example, it happens that on a 4x4
lattice CKB has no Trotter errors!  But this is a special case.
In general there are Trotter errors.  It sounds like Vlad might
have discovered a triangular lattice case where they
also commute, if he had no Trotter.

Richard Scalettar
Professor, Physics Department
One Shields Ave.
University of California, Davis 95616
fax   530-752-4717
email scalettar@physics.ucdavis.edu
http://scalettar.physics.ucdavis.edu/

Original comment by scalet...@physics.ucdavis.edu on 6 Aug 2014 at 8:24

[GoogleCodeExporter]

Thanks for the input Richard! You are correct: I ran my squad and triangular 
lattice tests on a 4x4 setting.
So I re-ran the same U=0 test for 6x6 square and triangular lattices again. 
This time, dense matrix and 
checkerboard give different results:

6x6 square lattice ---
square6x6_CKB_L10_dtau0.1      :  Kinetic energy :  -0.12590375E+01 +-  
0.00000000E+00
square6x6_CKB_L100_dtau0.01    :  Kinetic energy :  -0.12588415E+01 +-  
0.00000000E+00
square6x6_CKB_L1000_dtau0.001  :  Kinetic energy :  -0.12588395E+01 +-  
0.00000000E+00
square6x6_denseB_L100_dtau0.01 :  Kinetic energy :  -0.12588395E+01 +-  
0.00000000E+00

6x6 triangular lattice ---
triangular6x6_CKB_L10_dtau0.1      :  Kinetic energy :  -0.16712589E+01 +-  
0.00000000E+00
triangular6x6_CKB_L100_dtau0.01    :  Kinetic energy :  -0.16710688E+01 +-  
0.00000000E+00
triangular6x6_CKB_L1000_dtau0.001  :  Kinetic energy :  -0.16710669E+01 +-  
0.00000000E+00
triangular6x6_denseB_L100_dtau0.01 :  Kinetic energy :  -0.16710669E+01 +-  
0.00000000E+00

And as dtau becomes smaller, CKB energy is getting closer to the exact one.
So 4x4 is indeed a special case, even for triangular lattice.

Original comment by cxc639 on 6 Aug 2014 at 9:29

Attachments:

• test.out_square6x6_CKB_L10_dtau0.1
• test.out_square6x6_CKB_L100_dtau0.01
• test.out_square6x6_CKB_L1000_dtau0.001
• test.out_square6x6_denseB_L100_dtau0.01
• test.out_triangular6x6_CKB_L10_dtau0.1
• test.out_triangular6x6_CKB_L100_dtau0.01
• test.out_triangular6x6_CKB_L1000_dtau0.001
• test.out_triangular_denseB_L100_dtau0.01

[GoogleCodeExporter]

If everyone is OK with these test results, I'm going to close the issue.

Original comment by cxc639 on 8 Aug 2014 at 6:16

[GoogleCodeExporter]

Is there an option to mark the issue as resolved, but not closed so that we
can
refer to it in the future if encountered similar issues?

Original comment by ehsankha...@gmail.com on 8 Aug 2014 at 2:16

[GoogleCodeExporter]

I am wondering the same thing too. But I could not find a solution. It would be 
good if we could 
have a archive for issue trackers.

Anyway, I can add a section in WIKI discussing the checkerboard decomposition. 
This may also 
benefit QUEST's potential users. After the WIKI thing is done, I'll close the 
ticket.

Original comment by cxc639 on 8 Aug 2014 at 4:43

[GoogleCodeExporter]

Ehsan created this issue about 2 problems. (Ehsan, rule of the thumb is - one 
problem => one issue)

second one is about checkerboard decomposition, and you are right, after 
creating WIKI page we are done wit this problem, but second one is about L = 1.

L = 1 gives non physical values, this is true, but it is not obvious by default 
if you do not know how DQMC algorithm works. So, I believe QUEST should have 
check in the code for L > 1 and give an error if L = 1 in the input file.

L = 1 problem looks small, but it still exists. I think we should close this 
issue after both problems are fixed (It is inconvenient, but that is how Ehsan 
started this). Or we can close this issue and create new one concerning L = 1.

Original comment by iglovi...@gmail.com on 8 Aug 2014 at 7:18