Broken geometric conventions in dslash_eo? (Defect #387)

Added by Christopher Pinke over 6 years ago. Updated over 6 years ago.

Status:New Start date:09 Jan 2013
Priority:High Due date:
Assignee:Christopher Pinke % Done:


Target version:-


In d8715f4d the lines

if(evenodd == ODD) get_odd_site(id_tmp, &n, &t);
else get_even_site(id_tmp, &n, &t);

were changed to

st_index pos = (evenodd == ODD) ? get_even_site(id_tmp) : get_odd_site(id_tmp);

Am I right that this also changes the if statement? This would explain a lot, because I found that if the dslash is used to give an even/odd vector, it really returns an odd/even vector.
Essentially, this means all our conventions are twisted.

Related issues

blocks CL2QCD - Defect #389: Check on Inversion with even-odd-preconditiong In Progress 12 Jan 2013 30 Apr 2013
blocked by CL2QCD - Feature #361: Base hmc on new classes Done 14 Jan 2013

Associated revisions

Revision fc740c91
Added by Christopher Pinke over 6 years ago

edited workaround for #387 in inversion in gaugefield_inverter
refs #341
refs #387

Revision c9b6ede9
Added by Christopher Pinke over 6 years ago

added workaround to #387 to give correct inversion in eo case to inversion.cpp
refs #341
refs #387


Updated by Matthias Bach over 6 years ago

I remember having talked with you about this line looking strange, but we came to the conclusion, that it is correct. However, no looking at the commit that introduced it, it definetly looks like a bug.

Does fixing that line fix your problem?

Updated by Christopher Pinke over 6 years ago

Well, actually yes, as I am currently working in the inverter.
However, I think this will affect all of the tests where the dslash is involved and especially the HMC itself. Therefore I would suggest that I implement a workaround in the inverter for now so as not to rush things. Since we carried out already many HMC simulations I want to check carefully how the HMC is affected. An alternative is of course to "really" switch the convention, this would of course mean touching a lot of code.

Updated by Matthias Bach over 6 years ago

I fear a local workaround will only create more problems in the long run.

The commit changed the if-statement, which looks like an accidental change. Therefore I don't really see why fixing it requires changing our conventions. It looks more like currently it's actually simply returning wrong values from the Dslash.

Updated by Christopher Pinke over 6 years ago

If we would change the if-statement back now this would imply many changes:
  • all even/odd input vectors to any dslash calls must then be interpreted as odd/even
  • we have to touch all tests involving dslash, because these will give different results
  • we have to carefully go through all HMC parts and change them accordingly
  • especially we have to check the force, too, which should require a change similar to the dslash

I think this not easily done, I would guess at least one week of testing. On the other hand, the workaround consists of taking the situation as it is: When I read in the source vector for the inversion, I convert it to even-odd vectors. If I now interprete the even vector as odd and the odd vector as even, everything is fine, thus two lines have to be changed.

Updated by Matthias Bach over 6 years ago

So basically, while d8715f4d looks like a bug, all code around it has been written according to the convention implied by this change, not to the one originally intended? Yes, in that case it would probably be easier to just also change the convention for the source vector.

Updated by Christopher Pinke over 6 years ago

  • Assignee changed from Matthias Bach to Christopher Pinke

Also available in: Atom PDF