Issue with decomposition of tHq process into quadratic and interference terms

Asked by Florian Mausolf

Dear experts,

I am trying to simulate tHq production with CP-odd admixtures in the top-Yukawa using the NLO Higgs Characterisation model from http://feynrules.irmp.ucl.ac.be/wiki/HiggsCharacterisation in MadGraph version 2.9.18.

Ideally, I would like to have samples allowing for a continuous modelling of the process in the plane of CP-even and CP-odd top-Yukawa coupling modifiers (labelled `kHtt` and `kAtt` in the HC model) at NLO, by simulating the quadratic and interference terms individually and stitching samples together afterwards with according weights.

In the HC model, the HWW coupling is labeled with coupling order `QNP: 1`, while the Htt and Att couplings are not labeled.
For the SM tHq process, diagrams with top-Higgs coupling, W-Higgs coupling and their destructive interference contribute mostly.
As first test, I tried to retrieve the SM tHq result from the model when simulating the HWW and Htt quadratic terms and their destructive interference separately.
However, the results I received are inconsistent at LO and fail at NLO.

I use the following syntax to generate the SM tHq process (at LO here for tests):
```
import model HC_NLO_X0_UFO

generate p p > t x0 b~ j $$ w+ w-
add process p p > t~ x0 b j $$ w+ w-

```
Using the default run_card, I get a cross-section of 54fb.

I expected to receive the same result by simulating the quadratic Htt and HWW terms and their interference separately and adding up the cross-sections.

For the simulation of the quadratic Htt and HWW terms, I set other relevant couplings to zero.
So for the Htt quadratic term, I set `kSM` (scaling HWW) and `kHbb` (playing minor role here) to zero, the cross-section I get is 173fb.
To generate the HWW quadratic terms only, I set `kHtt` and `kHbb` to zero, resulting in a cross-section of 200fb.

Then, I use the following syntax for the Htt-HWW interference (no significant change observed when setting kHbb to zero or not):
```
import model HC_NLO_X0_UFO

generate p p > t x0 b~ j $$ w+ w- QNP^2==1
add process p p > t~ x0 b j $$ w+ w- QNP^2==1
```
The result is a cross-section of -216fb.
The sum of these three contributions is then approximately (200 + 173 - 216) fb = 157 fb, which is far away from the 54 fb I expected.
Do you know what might be wrong in this setup, causing the cross-sections not to add up?
As a cross-check, I tested how these three terms scale with the relevant coupling modifiers.
There are the quadratic and linear dependences on the modifiers as expected.

In order to also allow for explicit simulation of possibly relevant Htt-Att and Att-HWW interferences, we slightly changed the model such that the Htt and Att couplings are labelled with coupling orders `NPkth: 1` and `NPkta: 1`, respectively.
We made adaptions in the coupling_orders.py, couplings.py and CT_couplings.py, the adapted model can be found here: https://cernbox.cern.ch/s/ee7jEZ4gT4fez1w
With this modified model and the following syntax, I receive the same result for the quadratic Htt term, for example, as described above when setting kSM and kHbb to zero:

```
import model HC_NLO_X0_UFO_MOD

generate p p > t x0 b~ j $$ w+ w- NPkth==1
add process p p > t~ x0 b j $$ w+ w- NPkth==1
```
However, when requiring `NPkth^2==2`, which I expected to equivalently include the quadratic Htt-contributions only, the result changes (cross-section of 119 fb instead of 173 fb). This also appears when using the original model and doing the same with `QNP` for the HWW quadratic term.
Is this difference expected?
If so, what is the correct syntax for NLO simulation? I see that QNP==1 is not allowed at NLO.

Lastly, I would like to understand the following: going to NLO, I see errors in the pole checks for each of the interference terms.
Example syntax for Htt-HWW interference with the original model:
```
import model HC_NLO_X0_UFO

generate p p > t x0 b~ j $$ w+ w- QNP^2==1 WEIGHTED<=7 [QCD]
add process p p > t~ x0 b j $$ w+ w- QNP^2==1 WEIGHTED<=7 [QCD]
```
Here, I added `WEIGHTED<=7` because otherwise, I see this error:
Command "import /.automount/net_rw/net__scratch_cms3a/mausolf/NLO_samples/standaloneMG/CMSSW_13_2_4/src/MG5_aMC_v2_9_18/bin/cards/tHq_4f_NLO_MH125_kHtt_kHWW_HC.dat" interrupted in sub-command:
"generate p p > t x0 b~ j $$ w+ w- QNP^2==1 [QCD]" with error:
FKSProcessError : Cannot map born/real configurations between g u > x0 t b~ d [ all = QCD ] QNP^2==1 $$ w+ w- and g u > x0 t b~ d g WEIGHTED<=3 [ all = QCD ] QNP^2==1 $$ w+ w- (i,j=7,1): not same number of configurations: 8 0

Now, running the command from above, I get the pole cancellation error:
INFO: Result for check_poles:
Error detected in "launch auto "
write debug file /.automount/net_rw/net__scratch_cms3a/mausolf/NLO_samples/standaloneMG/CMSSW_13_2_4/src/MG5_aMC_v2_9_18/bin/tHq_4f_NLO_MH125_kHtt_kHWW_HC_NLO/run_01_tag_1_debug.log
If you need help with this issue please contact us on https://answers.launchpad.net/mg5amcnlo
str : Poles do not cancel, run cannot continue

Before, I see these warnings: WARNING: Some loop diagrams contributing to this process are discarded because they are not pure (QCD)-perturbation.
Make sure you did not want to include them.

I tried the suggestion from https://answers.launchpad.net/mg5amcnlo/+faq/2720 to set
#IRPoleCheckThreshold and #PrecisionVirtualAtRunTime to -1d0. With this, I get a positive cross-section (49 fb) for the destructive interference, so this solution does not appear to be valid here.
Do you have any suggestion how to fix this pole cancellation issue at NLO here which could still provide the correct physics?
Perhaps something else is wrong here since the results at LO already do not agree?
Or is this a conceptual issue that the interference terms cannot be computed separately?

I would greatly appreciate any guidance on the questions I raised here.

Many thanks in advance and best wishes.

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Olivier Mattelaer
Solved:
Last query:
Last reply:
Revision history for this message
Best Olivier Mattelaer (olivier-mattelaer) said :
#1

For LO, the main issue is typically the (arbitrary) choice of the scale.

Since the default of MG5 is to
1) have a running scale
2) define the scale based on the diagram contributing according to the phase-space parametrization.

While the choice is arbitrary and can be freely be choose, this is certainly ok to do.
However this method choose different running scale for term of your above computation.

Therefore you do not expect that the sum of the term agrees with the computation where you do integrating everything simultaneously (within statistical uncertainty). The agreement will/should be present only within scale uncertainty.

Assuming that the scale uncertainty is around 40% and no correlation between the error then the sum should be
157 fb +- 120 fb # this error is so large since you substract a large number.
that need to be compare to something like
54 +- 20 fb
So without looking at the detail, it seems to be ok to my point of view.

Obviously, if you change the running scale to something purely kinematic (like HT/2) or even fix scale, then the agreement will/should be at the level of statistical uncertainty.

> changes (cross-section of 119 fb instead of 173 fb). This also appears when using the original model and doing the same with `QNP` for the HWW quadratic term.
Is this difference expected?

I would say that this is indeed expected and normal, if you check the run_card for both run, you will see that the case QNP=1, is using the default dynamical scale (-1) which is the one I described above, while in principle QNP^2==2, has default dynamical scale (3) (which is HT/2) since this syntax is designed for interference, we prefer not to have a dependence of the amplitude square of the diagram to select the scale.

So the difference between the two is, as above, the scale dependence, and this shows that my above (rule of thumb) 40% of scale uncertainty seems to be reasonable.

For NLO, my suggestion would be to not use 2.9 but move to version 3 of the code since that version is able to handle multi-expansion NLO computation which is clearly require for the type of computation that you are trying.
I would also suggest to create a separate issue on that if you still have issue with that with that version since this will likely need different people within our team to answer you if you have issue (and having multiple question within the same thread is always confusing).

Cheers,

Olivier

Revision history for this message
Florian Mausolf (flomau) said (last edit ):
#2

Thank you very much, Olivier!
That solved my question for the LO part, while I'm trying your suggestion of using version 3 for the NLO simulation.

Cheers
Florian