etmc / tmLQCD

tmLQCD is a freely available software suite providing a set of tools to be used in lattice QCD simulations. This is mainly a HMC implementation (including PHMC and RHMC) for Wilson, Wilson Clover and Wilson twisted mass fermions and inverter for different versions of the Dirac operator. The code is fully parallelised and ships with optimisations for various modern architectures, such as commodity PC clusters and the Blue Gene family.
http://www.itkp.uni-bonn.de/~urbach/software.html
GNU General Public License v3.0
32 stars 47 forks source link

Lorentz bug: correlator on unit gaugefield with periodic BC is not identical in all four directions #304

Closed m-schroeck closed 8 years ago

m-schroeck commented 8 years ago

-set unit gaugefield -set source to zero except on site ix=0, there set it to 1 for all color and spin indices -set boundary conditions to periodic in all four directions -set the same lattice size in all four directions -invert the twisted mass operator on that source -construct (pion like) correlator along each space-time dimension, e.g. along t with x=y=z=0 and equivalently along x,y,z with the other indices zero -the four resulting correlators should be the same, but only two agree (along y and z), the other two are not even symmetric!

lorentz-bug

To reproduce the bug, see https://github.com/m-schroeck/tmLQCD/tree/lorentz-bug which contains minimal changes from invert.c and an adequate input file which is:

L = 16
T = 16

DebugLevel = 3 2kappaMu = 0.05 kappa = 0.177 BCAngleT = 0 DisableIOChecks = yes UseRelativePrecision = no UseEvenOdd = yes OmpNumThreads = 1 NoSamples = 1 SourceType = Volume

BeginOperator TMWILSON 2kappaMu = 0.05 kappa = 0.177 UseEvenOdd = yes Solver = CG SolverPrecision = 1e-20 MaxSolverIterations = 10000 EndOperator

Details: most basic configure: CC=mpiicc --disable-omp --disable-mpi --disable-gaugecopy --disable-halfspinor --with-limedir=${limedir} --with-lapack="-mkl=parallel" Compiler: icc (ICC) 15.0.2 20150121

Please try to reproduce the bug. In case I'm doing something stupid, please let me know :)

m-schroeck commented 8 years ago

Exact same problem with gcc (GCC) 4.9.2

urbach commented 8 years ago

@kostrzewa @m-schroeck okay, started to look into this. First observation is that the averaged correlators (forward/backward) are identical for all 4 directions

urbach commented 8 years ago

now, if I use a different source, namely delta sources for instance like this

for( int is=3; is<4; is++ )
   for( int ic=2; ic<3; ic++ ) {
      p_cplx_src[is*3+ic] = 1.0;
   }

for all possible spin/colour combinations, I get identical correlators in all four directions

urbach commented 8 years ago

the same if there is a 1 in all three colour components

urbach commented 8 years ago

now I set two spin components at the same time, like this

for( int is=1; is<3; is++ )
   for( int ic=0; ic<3; ic++ ) {
      p_cplx_src[is*3+ic] = 1.0;
  }

for is=(0,1) and is=(2,3) all correlators are identical, for is=(1,2) and is=(0,3) X and Y differ from identical T and Z

urbach commented 8 years ago

adding the combinations is=(0,2) and is=(1,3), for which T and Z differ from identical X and Y

urbach commented 8 years ago

with twisted mass set to zero the discrepancy is only in the T direction

urbach commented 8 years ago

Why was the source chosen like this?

With delta sources we get the correct result. Setting all 12 elements to 1 leads to unwanted contributions in the inverse. And they'll not cancel (which they would in the full theory due to gauge invariance). Might this explain the seen effect?

m-schroeck commented 8 years ago

Hi Carsten, I had chosen the source like that not for physical reasons but while trying to match the tmLQCD operator with the qphix tm operator. Mario

urbach commented 8 years ago

and you are saying this does not happen with the qphix tm operator?

Independently of this, this source mixes all gamma matrices in in the correlator, doesn't it?

m-schroeck commented 8 years ago

Well, I still had problems matching the two operators but as far as I can remember that didn't occur in the qphix operator. I've tested this as a step towards sources with Zn noise.

urbach commented 8 years ago

with stochastic sources the story is different.

When we test the result of the Quda inverter, we do not observe a deviation, correct? @kostrzewa

m-schroeck commented 8 years ago

I don't think that this occurs with Quda

urbach commented 8 years ago

but we cross-check the propagator produced by Quda. We should see a deviation, if there is any, shouldn't we?

m-schroeck commented 8 years ago

You're right, the actual operators agree when comparing tmLQCD and Quda..

kostrzewa commented 8 years ago

After fixing the residual definitions (such that both QUDA and tmLQCD compute the inverse of (D D^dagger) and post-multiply with D^dagger to get D^(-1), the residuals reported by QUDA and the one in the post-inversion check of tmLQCD are always of the same order of magnitude and most of the time agree to some significant digit. If that is the case, I do not see how the resulting correlators could disagree. I did not do any tests using trivial gauge configurations. I did test with point sources and stochastic sources of various kinds, however.

m-schroeck commented 8 years ago

I'm not saying it's a bug in the actual operator. But as far as I remember, when I tested the same thing completely independent of tmLQCD with e.g. Quda I didn't find that behavior.

kostrzewa commented 8 years ago

Does it also happen with the halfspinor operator?

kostrzewa commented 8 years ago

Oh, yes I remember it does. You tested that in our last exchange.

urbach commented 8 years ago

it would be interesting to try tmLQCD with Quda inverter. Can the Quda inverter be called from your branch, Mario?

to sum up:

correct?

What do we expect for this kind of source?

kostrzewa commented 8 years ago

Can the Quda inverter be called from your branch, Mario?

no, we pulled in the quda interface a long time after this bug was submitted

urbach commented 8 years ago

but we could copy invert.c

urbach commented 8 years ago

Also after some discussion with Bartek, it seems to me that this is not a bug, but due to the special source choice: due to the source you will not compute the "pion" correlator, but a mixture of all possible gamma-matrices at sink. If one of these happens to be a sinh, it can explain the observed behaviour. And due to the mixture the correlators also get some dependence on the direction.

For me the biggest evidence for the above explained scenario is that when I use point source (i.e. delta in spin and colour), there is no dependence on the direction and by multiplying the correlator with a factor of 12 I get the same result as in the Y and Z direction with "wall source". Moreover, a sinh contributions gets averaged out when +t and -t are averaged.

This can be further checked in the following way:

Does this make sense?

urbach commented 8 years ago

I have just summed the 12 propagators obtained with delta sources, and the result agrees up to round off with the "wall source" result. Does this clarify this problem sufficiently?

m-schroeck commented 8 years ago

While of course each delta source gives identical correlators in each direction as you have confirmed before - this should in fact explain the behavior I guess. Thanks for checking.

urbach commented 8 years ago

Thanks to you, Mario. Of course, it would be nice to check analytically why in some directions sinh like correlators appear.

urbach commented 8 years ago

so, could we close this issue @m-schroeck @kostrzewa ?

m-schroeck commented 8 years ago

yes