EVOL: Top msbar mass running
Closed this issue · 10 comments
We believe the routine computing the top mass evolution in the msbar scheme
is not working properly in case more than one flavour patch is present.
In particular in file MSbarmass.f:
ELSEIF(Q2.GE.M2TH(4).AND.NFMAXALPHA.GE.4)THEN
EVF = DECOUP("DW",5,DLOG(K2TH(5)))
1 / EVMASS(4,ASQ,ASIM)
2 * DECOUP("DW",6,DLOG(K2TH(6)))
3 / EVMASS(5,ASTH(5),ASTHM(6))
ELSE
EVF = DECOUP("DW",4,DLOG(K2TH(4)))
1 / EVMASS(3,ASQ,ASIM)
2 * DECOUP("DW",5,DLOG(K2TH(5)))
3 / EVMASS(4,ASTH(4),ASTHM(5))
4 * DECOUP("DW",6,DLOG(K2TH(6)))
5 / EVMASS(5,ASTH(5),ASTHM(6))
we propose the following fix:
ELSEIF(Q2.GE.M2TH(4).AND.NFMAXALPHA.GE.4)THEN
EVF = DECOUP("DW",5,DLOG(K2TH(5)))
1 / EVMASS(4,ASQ,ASTH(5))
2 * DECOUP("DW",6,DLOG(K2TH(6)))
3 / EVMASS(5,ASTH(5),ASIM)
ELSE
EVF = DECOUP("DW",4,DLOG(K2TH(4)))
1 / EVMASS(3,ASQ,ASTH(4))
2 * DECOUP("DW",5,DLOG(K2TH(5)))
3 / EVMASS(4,ASTH(4),ASTHM(5))
4 * DECOUP("DW",6,DLOG(K2TH(6)))
5 / EVMASS(5,ASTH(5),ASIM)
We found good agreement with the Eko implementation (WIP) and the fixed apfel routine.
Hi Giacomo, thanks for spotting it.
That looks fine to me.
Please, open a pull request.
@vbertone I fixed it, but I'm not allowed to push.
@vbertone I fixed it, but I'm not allowed to push.
The workflow should be:
- make your own fork of the repo
- fix it there
- open a PR across repos
@giacomomagni I have just implemented the fix that you suggested above.
It's a small one and there's no need to open a pull request.
Thank you.
Okay thanks. I'll close the issue.
Hi @vbertone. We noticed 5b1de45 is not complete to fix this issue.
This change is still missing:
ELSEIF(Q2.GE.M2TH(4).AND.NFMAXALPHA.GE.4)THEN
EVF = DECOUP("DW",5,DLOG(K2TH(5)))
1 / EVMASS(4,ASQ,ASIM)
2 * DECOUP("DW",6,DLOG(K2TH(6)))
3 / EVMASS(5,ASTH(5),ASTHM(6))
ELSEIF(Q2.GE.M2TH(4).AND.NFMAXALPHA.GE.4)THEN
EVF = DECOUP("DW",5,DLOG(K2TH(5)))
1 / EVMASS(4,ASQ,ASTH(5))
2 * DECOUP("DW",6,DLOG(K2TH(6)))
3 / EVMASS(5,ASTH(5),ASIM))
Would you mind fix this as well? Thank you in advance for your collaboration.
Hi @giacomomagni, thanks for spotting this as well. It should be fixed now.
Sorry in advance, I might be missing something (I didn't fully analyze what is happening, so I don't perfectly understand).
About this fix and even the previous one: in the original version of the function, all the second arguments of EVMASS
where the M
variant (like ASTHM
), i.e. the value of the strong coupling below threshold.
Now there is even a non-M
variant. Is it fine like this? Was it part of the bug?
(as I said, I don't fully understand, so I was just observing the pattern, sorry if it's a stupid observation)
Hi @alecandido, you are totally right indeed!
In fact, the second argument of EVMASS
should always be of M
type because the evolution is done between consecutive thresholds and the upper value of alpha_s should be right below the threshold (as well as the lower value should be right above the threshold).
This bug should only affect calculations at NNLO because below this order alpha_s is continuous over thresholds (unless thresholds are displaced).
I'm going to fix it straight away. Thanks for spotting it!
Hi @vbertone and @alecandido thanks for fixing this both of you!