Adding LO EW corrections to 4H operators in tttt

[ecelada]

This PR updates the tttt datasets by including the LO EW correction in 4H operators, as suggested in https://arxiv.org/pdf/2208.04962. The same corrections are negligible on other operators.
Only the datasets that are currently used have been changed:

ATLAS_tttt_13TeV_2023
ATLAS_tttt_13TeV_slep_inc
ATLAS_tttt_13TeV_2023_proj
ATLAS_tttt_13TeV_slep_inc_proj
CMS_tttt_13TeV_2023
CMS_tttt_13TeV_slep_inc
CMS_tttt_13TeV_2023_proj
CMS_tttt_13TeV_slep_inc_proj

[jacoterh]

@ecelada thank you very much for taking care of this! Could you please elaborate a bit more on where in the paper you took these predictions from and why the change is so large for some of the operators? Thanks!

[ecelada]

@ecelada thank you very much for taking care of this! Could you please elaborate a bit more on where in the paper you took these predictions from and why the change is so large for some of the operators? Thanks!

Thanks @jacoterh for looking at this PR. The numbers are taken from Tables 8-9-10 in 2208.04962, and take into account the probably different scales. Both factorisation and renormalisation scales are set to 2 mt in the reference, while inspecting the numbers it looks like it was mt in the smefit computation (to be confirmed).

The reason for the change is that, as argued in https://arxiv.org/pdf/2208.04962, some operators receive the dominant contribution at order Lambda^-2 from the interference with SM amplitudes that are subleading in alpha_s, and considering purely QCD contributions as we generally do for these processes is wrong. The most affected operators are 4 heavy (cQQ8, cQt8, cQQ1, cQt1, ctt1), the LO EW corrections lead to even different signs in some cases.
The effect of LO EW interferences is smaller on other operators such as bosonic and 2H. In some cases like the dipoles in table 10, the LO EW terms are effectively the LO contribution and they are not included in the json at the moment. They should, in principle, however these operators are not mainly constrained by 4 tops and their contribution wouldn't have an impact in global fits so they weren't updated.

[jacoterh]

Table 8 in https://arxiv.org/pdf/2208.04962 gives -0.706 for OQQ1. I have tried to reproduce this number through a K factor approach, i.e. -0.706/0.242 * 0.37086 = -1.08, but I don't match. Can you please comment on how you obtained this number? Probably this explains then also the rest!

[ecelada]

My assumption, based on what Eleni told me but that I couldn't verify, is that the smefit numbers were computed at mt rather than 2 mt. In this way I could match the paper and our tables, for instance I get from table 8 that the purely QCD contribution is 0.242*1.54=0.37, which is the same of our result without the LO EW. That seems to work also for the other operators. So I used the same assumption for the LO EW, and took the total result from tab 8 at the different scale: -0.706 1.37 =-0.967. Of course this is based on the assumption that the scales are different, but I couldn't reproduce the numbers in any other way and in this way they seem to agree. It would be good if we could find the original runcards to verify this

[jacoterh]

Hi @ecelada , thanks for the clarifications. Can you please copy your LO numbers to a new key and call it, say, LO_QCD_EW so that it's clear these numbers contain LO EW?

@LucaMantani I had a look at the 4-top predictions and we ported them from the top study with SIMUnet if I'm not mistaken. Do you remember what scale you adopted? The scale uncertainties are quite large on the inclusive numbers, so this can make a sizeable difference.

[ecelada]

Hi @ecelada , thanks for the clarifications. Can you please copy your LO numbers to a new key and call it, say, LO_QCD_EW so that it's clear these numbers contain LO EW?

@LucaMantani I had a look at the 4-top predictions and we ported them from the top study with SIMUnet if I'm not mistaken. Do you remember what scale you adopted? The scale uncertainties are quite large on the inclusive numbers, so this can make a sizeable difference.

Done. Now this means that we have to remember in future runcards to specify the key LO_QCD_EW for these datasets.

[LucaMantani]

Hi @ecelada , thanks for the clarifications. Can you please copy your LO numbers to a new key and call it, say, LO_QCD_EW so that it's clear these numbers contain LO EW?

@LucaMantani I had a look at the 4-top predictions and we ported them from the top study with SIMUnet if I'm not mistaken. Do you remember what scale you adopted? The scale uncertainties are quite large on the inclusive numbers, so this can make a sizeable difference.

Unfortunately I can't access (at least in this moment) the Cambridge hpc where I should have the runs...

[jacoterh]

Hi @ecelada , the tests fail at the moment because pre-commit hasn't been run and LO_QCD_EW is not part (yet) of the allowed set of order identifiers. This can be fixed by running the precommit with pre-commit run --all-files and adding LO_QCD_EW to test_theory_orders_are_allowed.

[ecelada]

Hi @ecelada , thanks for the clarifications. Can you please copy your LO numbers to a new key and call it, say, LO_QCD_EW so that it's clear these numbers contain LO EW?
@LucaMantani I had a look at the 4-top predictions and we ported them from the top study with SIMUnet if I'm not mistaken. Do you remember what scale you adopted? The scale uncertainties are quite large on the inclusive numbers, so this can make a sizeable difference.

Unfortunately I can't access (at least in this moment) the Cambridge hpc where I should have the runs...

Hi @LucaMantani, did you manage to find the runs?

[LucaMantani]

Hi @ecelada , thanks for the clarifications. Can you please copy your LO numbers to a new key and call it, say, LO_QCD_EW so that it's clear these numbers contain LO EW?
@LucaMantani I had a look at the 4-top predictions and we ported them from the top study with SIMUnet if I'm not mistaken. Do you remember what scale you adopted? The scale uncertainties are quite large on the inclusive numbers, so this can make a sizeable difference.

Unfortunately I can't access (at least in this moment) the Cambridge hpc where I should have the runs...

Hi @LucaMantani, did you manage to find the runs?

Yes but they are not there, I am not sure I have ever run 4 tops

[ecelada]

Following discussion with @arossia94, I ran a few operators in MadGraph and verified that I could reproduce the numbers in the paper with mu = 2mt, and smefit numbers with mu=mt, both for the purely QCD and mixed EW-QCD

[jacoterh]

Great you double checked this with madgraph. We can now be sure everything is consistent between QCD and QCD + EW!

[jacoterh]

Hi @ecelada , why did the LO numbers change in this PR? We have added a separate LO_QCD_EW key, so I am not sure why also the LO numbers changed. I didn't see this before.

[ecelada]

Hi @ecelada , why did the LO numbers change in this PR? We have added a separate LO_QCD_EW key, so I am not sure why also the LO numbers changed. I didn't see this before.

can you point me to the change you are seeing?

[jacoterh]

For instance here and everything above is different compared to what was on main before

[ecelada]

I don't think the numbers changed, if you're looking at the git diff I think it appears different because for instance Ott1OtG changed to OtGOtt1 but numbers look the same to me

[jacoterh]

This came up because the test that checks for missing off-diagonal quadratics failed on main. This check was not present in this PR as we forgot to rebase unfortunately. The LO_QCD_EW seem fine, i.e. all cross-terms are present, but this is not the case for LO: not only do the numbers change with respect to what was on main before, but we also have new operators like OQb1, OQb8, Otb1, Otb8 and their quadratic cross-terms are not written, hence the failing test. But besides that, I'm mostly confused why the LO changed in the first place because this PR is about LO_QCD_EW only.

The fits use LO_QCD_EW and since these are fine we don't need to worry, but it'd be nice to clarify this.

[jacoterh]

See here for example for OQb1 that got added

[jacoterh]

For reference, this issue got resolved in a separate PR: #160