Broken geometric conventions in dslash_eo? (Defect #387)
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.
|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|
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.
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.
- 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.
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.