Bug in epsilon_K calculation
MJKirk opened this issue · 4 comments
In the meson mixing code, the wilson coefficients (specifically the loop functions) use the quark masses at a single fixed scale.
flavio/flavio/physics/mesonmixing/wilsoncoefficient.py
Lines 59 to 61 in 3b80329
However, these loop functions get multiplied by the QCD RG correction factors
flavio/flavio/physics/mesonmixing/amplitude.py
Lines 52 to 57 in 3b80329
where the values used assume the quark masses are mt(mt) and mc(mc) (see the first page of 1108.2036 for
eta_cc or section 2 of 1007.0684 for etc_ct).
For the B mixing observables it doesn't make a difference, since they only use the tt coefficient, and mt(160 GeV) is very close to mt(mt).
But for epsilon_K, the difference between mc(160 GeV) and mc(mc) is large, and gives a 20% difference to the numerical value of eps_K.
Since the flavio paramter m_c is already mc(mc) from the PDG, that is easy to fix - just use mc = par["m_c"]
The up mass doesn't matter, since it is so small - I would again just use the PDG value par["m_u"] which is the MSbar mass at 2 GeV.
For the top, as I said before numerically it doesn't matter. But for correctness I think the easiest thing to do would be add a get_mt_mt function to the running module. RunDec has a function (mOS2mSI) to do this, so we can just use that.
I can submit a pull request if you agree with the issue.
Hi @MJKirk, thanks for reporting this! I have to take a closer look at the papers. But I am wondering if, when updating the implementation of epsilon_K, we should directly implement the more recent and more precise results from https://arxiv.org/abs/1911.06822. What do you think?
Yes probably. But that's more than a quick 3 line fix 😆
I would also note that using the current (but fixed) flavio implementation and similar inputs to that paper, you get an uncertainty of about 0.23, close to their 0.18, so I think it would be reasonable to do the quick fix now so flavio is at least correct (if a bit less precise). And then work on the newer formula next
I've made the simple fix to the epsilon_K code here: 68d2a4b, which could be pulled now.
I'm also happy to work on the newer formula, since I have some interest in this being done, but it could easily be next month before I get around to it.