# NLO cross-section for SM processes

Asked by Didier Alexandre on 2017-12-05

Dear experts,

I am trying to calculate the NLO cross-section of the following process:

import model sm
define p = g u c d s u~ c~ d~ s~
define j = g u c d s u~ c~ d~ s~
add process p p > b~ w- b j / z a [QCD]

It appears that this is not converging, as one single 10k events job has been running for days. Therefore I would like to ask you if you could point me to any hint as to why the calculations would not converge. For example, does this command generate any loop diagrams that are IR or UV divergent, and if yes, is there a way I can remove them?

Didier

## Question information

Language:
English Edit question
Status:
For:
Assignee:
marco zaro Edit question
Last query:
2017-12-05
2018-01-15
 marco zaro (marco-zaro) said on 2017-12-06: #1

Dear Didier,
what exactly are you interested in? in particular, why are you vetoing photons and z?
At which stage you have a job that takes so much? grid set-up / integration / event generation?
Are you changing any parameter in the run/param cards or in the code?

Thanks!

Cheers,

Marco

 marco zaro (marco-zaro) said on 2017-12-14: #2

Dear Didier,
is there any news on this question?
Thanks,

Marco

 Didier Alexandre (didieralexandre) said on 2018-01-12: #3

Hi Marco,

What I am trying to do is to calculate the NLO/LO ratio of cross-sections of the interfering background of Y(-4/3e) vector-like quarks. I did not reply sooner because it was still not clear which processes exactly are participating in that interference. This is now cleared up and all those processes can be generated with the following command:

define p = g u c d s u~ c~ d~ s~ b b~
define j = g u c d s u~ c~ d~ s~
generate p p > p p > j w- b / p t t~ z h a TWB^2==4

Where TWB^2 is the square coupling order referring to tWb vertices.

Before I deal with trying to use the square coupling order in a NLO generation (not sure if it even works) I am trying the following generation, which also includes several processes that do not participate in the interference, but I think that is ok as a first approach - in any case I want to find out if the NLO/LO cross-section is compatible with unity or if there is a considerable deviation.

define bb = b b~
generate bb p > w- b j [QCD]

With these command MG doesn't seem to be able to compile the P0* directories. This is the tail of the output:

generate 16:11:31 INFO: Starting run
generate 16:11:31 INFO: Compiling the code
generate 16:11:32 INFO: Using built-in libraries for PDFs
generate 16:11:32 INFO: Compiling source...
generate 16:11:41 INFO: ...done, continuing with P* directories
generate 16:11:41 INFO: Compiling StdHEP (can take a couple of minutes) ...
generate 16:12:07 INFO: ...done.
generate 16:12:07 INFO: Compiling directories...
generate 16:12:07 INFO: Compiling on 1 cores
generate 16:12:07 INFO: Compiling P0_bd_wmbu...
generate 16:12:09 WARNING: fct <function compile_dir at 0x25c9668> does not return 0. Starts to stop the code in a clean way.

If you could provide me with a hint of why this is the case, that would help me further.

Didier

 marco zaro (marco-zaro) said on 2018-01-15: #4

Hi Didier-Alexandre,
for the NLO generation, which model are you using? the default sm (and loop-sm which is loaded automatically when you do NLO) has a massive b. Since you have b's in the initial state, you should load the loop_sm-no_b_mass model before generating the process...
Does it work?

cheers,

Marco

 Didier Alexandre (didieralexandre) said on 2018-01-15: #5

Hi Marco,

I tried your suggestion. Indeed it makes sense to use that model since I am using the 5-flavour scheme. Unfortunately, that makes no difference on the problem I am facing. The production still gets stuck at the same place, that is, at the compilation of the P0* directories.

Cheers,
Didier

 marco zaro (marco-zaro) said on 2018-01-15: #6

did you activate the complex-mass scheme (set complex_mass_scheme True) before the generation? you have intermediate resonances, so you need to activate it...
also, look at section 3 here
https://arxiv.org/pdf/1603.01178.pdf
for more details.
Cheers,

Marco