Relative momenta orbit representatives mismatch between Markus und myself

[martin-ueding]

Before my code would just compute the correlation function for every possible relative momentum that fits the cutoff. This was redundant because picking a single one from a little group orbit is sufficient. Now the code is optimized in a way that it just picks one relative momentum per orbit.

As expected the choice that I made is different from the one that Markus did. This means that the comparison does not work any more. My code produces the following operators (though in Markus's convention!):

total_momentum_str	irrep	element
001	E	p: 1, q: (-1.0, 0.0, 0.5), g: \gamma{5}, \gamma{5}
001	E	p: 1, q: (-1.0, -1.0, 0.5), g: \gamma{5}, \gamma{5}
001	E	p: 1, q: (0.0, -1.0, -0.5), g: \gamma{5}, \gamma{5}
001	E	p: 1, q: (-1.0, -1.0, -0.5), g: \gamma{5}, \gamma{5}

He however has the following in his rho_p1_E_gevp-indices.tsv:

id  element
0   p: 1, g: \gamma_{50i}
1   p: 1, g: \gamma_{i}
2   p: 1, q: (0.0, 1.0, 0.5), g: \gamma_{5}, \gamma_{5}
3   p: 1, q: (1.0, 1.0, 0.5), g: \gamma_{5}, \gamma_{5}

One has to keep in mind that both of these q are to be taken in a frame where the total momentum is rotated to the reference direction. This way all the operators have the same parametrization even though the whole kinematics are rotated. Perhaps I have screwed this up somewhere in the process and my q labels are wrong.

The more likely case is that we just have picked different conventions. Markus has picked them by hand, I just sorted them and took the first one. Very likely we get different choices. Now there are a few options to get the comparison back working:

1. We just let my code redundantly compute all the different q again and for the comparison just pick out what we need. This will take minimal programming effort but will take a bunch of computer time and that will be annoying.

2. The analytic projection code could also write out the orbits as JSON and then the comparison code would match them up this way.

3. We try to get the same unique choices that Markus has done, though this would not generalize easily to three pions. As the choice should not matter at all, I don't want something too fancy in the analytic code.

I'm very much in favor of the second option and I'll serialize the orbits next.

[martin-ueding]

These orbits can now be serialized from Mathematica and the comparison code uses them to normalize Markus's choice to mine.

[martin-ueding]

Okay, it isn't this easy of course. I have broken the P=001 A1 which used to work before.

[martin-ueding]

If we take a look at the latest version with the older code we can see that there were more operators and that apparently I have mixed up the ones which were formerly called 000 and 00-1.

I'll need to think about this a bit more, then.

[martin-ueding]

Pro tip: Use as.numeric and not as.integer when you expect decimal numbers 🤦‍♂️