gg>h>z{T}z{L}

the command I used is g g > h > z{L} z{T} [noborn=QCD]

Hi,

Looks like loop-induced process is less secure than tree-level computation for polarised amplitude.
If I'm doing the same computation in the heft model (which I aggree is not the best idea for this particular process) I have the following warning first, followed by a close to critical error:

MG5_aMC>generate g g > h > z{T} z{L}
"L" polarization is interpreted as Left for Longitudinal please use "0".
Not Supported syntax:
   Syntax like p p > Z{T} Z are ambiguious Behavior is not guarantee to be stable within future version of the code. Furthemore, you can have issue with symmetry factor (we do not guarantee [differential] cross-section. We suggest you to abort this computation
Do you want to continue [no, yes][60s to answer]

If you do the same syntax at loop-induced, you only have the first warning, and looks like we do not detect the issue that you have two Z with sometimes identical heliticy and sometimes non identical helicity.

But I guess your real problem here is not how we handle symmetry factor (so the second warning) but the first warning that
"L" means LEFT polarization while you want to use "0" which means Longitudinal.

Cheers,

Olivier

Thanks a lot for your immediate response!

Actually, I tried g g > h > z{0} z{T} [noborn=QCD] or g g > h > z{0} z{L} [noborn=QCD] in standard model too, and it still can generate Feynman diagrams and the output is just like lines below:

MG5_aMC>generate g g > h > z{T} z{0} [noborn=QCD]
INFO: Checking for minimal orders which gives processes.
INFO: Please specify coupling orders to bypass this step.
INFO: Trying coupling order WEIGHTED<=4: WEIGTHED IS QCD+2*QED
INFO: Trying coupling order WEIGHTED<=5: WEIGTHED IS QCD+2*QED
INFO: Trying coupling order WEIGHTED<=6: WEIGTHED IS QCD+2*QED
INFO: Trying coupling order WEIGHTED<=7: WEIGTHED IS QCD+2*QED
INFO: Contributing diagrams generated: 0 Born, 4 loops, 2 R2, 0 UV
1 processes with 4 diagrams generated in 0.147 s
Total: 1 processes with 4 diagrams

MG5_aMC>generate g g > h > z{0} z{L} [noborn=QCD]
"L" polarization is interpreted as Left for Longitudinal please use "0".
INFO: Checking for minimal orders which gives processes.
INFO: Please specify coupling orders to bypass this step.
INFO: Trying coupling order WEIGHTED<=4: WEIGTHED IS QCD+2*QED
INFO: Trying coupling order WEIGHTED<=5: WEIGTHED IS QCD+2*QED
INFO: Trying coupling order WEIGHTED<=6: WEIGTHED IS QCD+2*QED
INFO: Trying coupling order WEIGHTED<=7: WEIGTHED IS QCD+2*QED
INFO: Contributing diagrams generated: 0 Born, 4 loops, 2 R2, 0 UV
1 processes with 4 diagrams generated in 0.146 s
Total: 1 processes with 4 diagrams

How can we explain this?

Yes that is normal, we do not have any smart way (at generation time) to check which helicity combination are possible from those which are not. We actually have such kind of check at running time with a built-in filtering time of the relevant helicity, but this is a numerical code.

So if you compute the cross-section for generate g g > h > z{T} z{0} [noborn=QCD]
that helicity will be kept (since this the highest contributing helicity) but the associated cross-section will be super-small (and the code super slow since it is very difficult to generate events for null cross-section since what you are integrating is numerical noise.
(in top of that you are doing that for loop computation and the code will go to quadruple precision due to the inacurracy of the computation which is super slow)

So for the survey only, here is the output:

INFO: P0_gg_zTz0
INFO: Idle: 1, Running: 2, Completed: 0 [ current time: 12h48 ]
INFO: Idle: 0, Running: 2, Completed: 1 [ 7s ]
INFO: P0_gg_zTz0/G1.2 is at 7.51e-36 +- 6.89e-37 pb. Now submitting iteration #2.
INFO: Idle: 0, Running: 2, Completed: 5 [ 19.4s ]
INFO: P0_gg_zTz0/G1.2 is at 6.76e-36 +- 4.55e-37 pb. Now submitting iteration #3.
INFO: Idle: 0, Running: 2, Completed: 9 [ 41.9s ]
INFO: P0_gg_zTz0/G1.2 is at 6.37e-36 +- 2.87e-37 pb. Now submitting iteration #4.
INFO: Idle: 0, Running: 2, Completed: 13 [ 1m 25s ]
INFO: P0_gg_zTz0/G1.2 is at 6.43e-36 +- 1.57e-37 pb. Now submitting iteration #5.
INFO: Idle: 0, Running: 2, Completed: 17 [ 2m 51s ]
INFO: Survey finished for P0_gg_zTz0/G1.2 at 6.44e-36 +- 9.23e-38 pb
INFO: Idle: 0, Running: 0, Completed: 20 [ 2m 52s ]
INFO: End survey
refine 10000
Creating Jobs
INFO: Refine results to 10000
INFO: Generating 10000.0 unweighted events.
 === Survey statistics summary ===
combined statistics: 8m05s, Avg. ML timing = 1 ms, Min precision = 4.47e-08
   -> Stability { tot# : 73615 , UPS% : 82.3 , EPS# : 0 }
   -> Red. tools usage in % { CT_QP : 82.3 , Ninja_DP : 17.7 }
sum of cpu time of last step: 0 second
INFO: Effective Luminosity 1.7868796420025484e+39 pb^-1
DEBUG: channel G1.2 need to improve by 13.69 (xsec=6.4358e-36 pb, iter=5)
INFO: need to improve 1 channels
DEBUG: /Users/omattelaer/Documents/git_workspace/LTS/PROC_loop_sm_1/SubProcesses/P0_gg_zTz0/G1.2 : need 11500.0 event. Need 10 split job of 6267 points
- Current estimate of cross-section: 6.4358e-36 +- 9.2264e-38

So you can see that this is a super-small cross-section which in this case I would indeed not trust.

Cheers,

Olivier

Thanks a lot for all your help! It do help me a lot!

Best,
Mingxuan