Gluon-loop induced ZZ+2jets

You are indeed not generating what you intend to simulate.

For the process g g > z z d d~ for example you have many loop diagrams which are correction to the existing tree-level process with the two z-boson emitted from the d-quark line.
These diagrams are not even IR finite, so their inclusion is meaningless.

What you should do is either to consider only gluons in the final states or consider everything, that is:

p p > z z j j QED=2 QCD=99 [noborn=QCD]

but then making sure that you only include the genuine loop-induced diagrams and no loop corrections. The simplest way to do this in this situation is to code a filter that will retain only loops with a quark line running in the loop.
You can do so by editing the function 'user_filter' in <MG_ROOT>/madgraph/loop/loop_diagram_generation.py and set

        edit_filter_manually = False

to

        edit_filter_manually = True

at the beginning of the function and then add a filter like

            if any([abs(pdg) not in range(1,7) for pdg in diag.get_loop_lines_pdgs()]):
                 valid_diag = False

next to the other commented examples (in the ' for diag in self['loop_diagrams']:' loop).

When activated, you should see a message from the filter at generation time, saying something like:

WARNING:
    The user-defined loop diagrams filter is turned on and discarded 50 loops.

Then you can use the MG5aMC 'display diagrams' command to make sure that the resulting selected diagrams are indeed the loop-induced ones you intended to keep.

Cheers

Let me add also that you should make sure that the resulting matrix-elements are finite and have no IR or UV poles (as they should be since they are loop-induced). You can do so by simply computing the poles for one random PS point with

MG5_aMC> generate u u~ > z z u u~ [sqrvirt=QCD]
MG5_aMC> output
MG5_aMC> launch -f

And you should see a finite result (I add below an example of what I obtain for u u~ > z g, in presence of the filter mentioned in my previous message.):

[...]
|| Loop amplitude squared, must be finite:
| Finite = 2.2723882569595309e-04
|(| Pole residues, indicated only for checking purposes: )
|( Single pole = -2.8068215448968431e-18 )
|( Double pole = 1.1045086142911420e-32 )

Hello Valentin,

thanks for your rapid response! I tried your suggestion, which did remove diagrams according to the output, but upon displaying the diagrams I notice that most of them are NLO corrections to the q+qbar tree-level process [see example at 1]. It appears that the noBorn=QCD was ignored. I want to point out that I am using the 2_5_0_beta2.

I don't know if this would make the generation easier, but in the end we are of course interested in the prediction for ZZ+2jets. That is to say we don't need to keep the loop-induced diagrams separate from the tree level gg > Z Z j j. We'd just have to remove the the gg initial state from our other tree-level QCD MC. Thinking ahead, we might event want to merge samples to get the jet-multiplicity spectrum right.

Many thanks for your support
Philipp

[1] https://www.dropbox.com/s/sm4g8y3rmenkssp/noBorn_wrong_diagram.png?dl=0

Sorry, this was careless of me, if you want to keep all contributions, then you must also make sure that at least one Z-boson is emitted by the loop, that is the following filter:

            if any([abs(pdg) not in range(1,7) for pdg in diag.get_loop_lines_pdgs()]) or (23 not in diag.get_pdgs_attached_to_loop(structs)):
                 valid_diag = False

The mode 'noBorn' does not implement any filter on the loops but simply forces MG5_aMC to ignore tree-level diagrams and to square the loops against one another.
This brings me to the second point, regarding the fact that the loop-induced contribution must be considered separately from the other contributions because the loop amplitudes are squared against themselves.

Even if you are doing p p > z z j j at NLO with MG5_aMC and that you see the same "loop-induced" loop diagram, it is *not* the same contribution because in that case that loop amplitude will be squared against the Born amplitude. In this case, the "loop-induced contribution" is a gauge invariant subset of (finite) NNLO contributions that you can include in your simulation independently of any other contribution (without fear of double-counting).

And if you see loop diagrams that are not loop-induced in the 'noborn' simulation (like the one you attached) then you *cannot* include it because it IR and UV divergent (since it is part of the NLO contribution to that process and they must be considered together with the corresponding real-emission diagrams). So it is useful to perform the test I indicated in my last message to verify that the loop-induced contribution you plan on integrating is indeed finite.

Finally, you can indeed perform merging with loop-induced simulations, exactly like you would for the usual LO simulations.

Hello Valentin,

so to recap/check my understanding:

A) The loop-induced diagrams for regular NLO will be shown because to have a complete fixed-order calculation, I also need to consider the cases where I add 2 vertices in one diagram (the one that will have the loop) but square it with a tree-level.

B) The diagrams that will be removed with the updated filter *have* to be removed because they will yield divergencies that won't cancel because the real emissions are missing. Please correct me if I'm wrong, but did you mean to say NNLO correction to the ZZ+2jets because the diagram I showed has QCD=4 while NLO would be QCD=3?

C) I can safely merge my p p > z z j j QED=2 QCD=99 [noborn=QCD] filtered sample and my p p > z z j j QED=2 QCD=99 [QCD] sample without double counting.

Finally, because this process is quite challenging to simulate, do you recommend any optimisations other than using massless b quarks?

Thank you again for your prompt and insightful response!

You have three types of diagrams that MG5_aMC can compute for your process: the tree diagrams (born_tree), the loop diagrams that are corrections to underlying tree topologies (loop) and the loop diagrams which are UV and IR finite and are not corrections (loop-induced LI).

Below I will write 'p p > z z j j' to denote the process where at least one of the p or j pair is a quark.

Now several contributions can be computed from these:

born_tree x born_tree = LO for p p > z z j j and absent for g g > z z g g
(loop+LI) x born_tree = NLO for p p > z z j j and absent for g g > z z g g, necessitates 'real_emission_tree x born_tree' as well to cancel IR divergences in 'loop x born_tree'.
LI x LI = finite subset of the NNLO corrections for p p > z z j j and LO contribution to g g > z z g g.

With this laid down, let me answer your questions:

A) Correct, the fixed order NLO prediction must include the contribution LI x tree because it is of the same order as the order genuine loop x born_tree corrections.

B) In the case of g g > z z g g, there is no other diagrams to remove, so it's all fine. for p p > z z j j, you must indeed remove the 'loop' type of diagrams because they are IR and UV divergent so that the NNLO contribution 'loop x loop' would require (double-)real-emission diagrams as well as two-loop UV renormalization to even start making sense (but in any case you wouldn't want to include these contributions separately from the two-loop virtual ones and the real-virtual ones).

I stress again however that this is all because you are simulating the loop-induced contributions 'LI x LI' with '[noborn=QCD]'. When you are computing the NLO corrections to p p > z z j j (with '[QCD]'), you can and should of course keep all diagrams, because they will be squared against the tree-level Born only in this case.

C) Correct.

Your simulation is indeed challenging. As far as the loop-induced simulation is concerned, you don't have much of a choice but to bite the bullet (maybe doing only g g > z z g g will be slightly fast, but not significantly so, hence it is better to just do all flavors with the filtering I indicated before).
For the NLO simulation, there is again not much you can do, except making sure that you set the parameter 'nevt_job' in the NLO run_card to something reasonable (like 1000 events, but the optimal value will depend on the number of integration channels and the size of your cluster).

Hello Valentin,

it appears that generating events is actually possible (10k events in 8hrs on 200 cores )! However, the run fails :
Error when reading /ggZZ_loop_v2/SubProcesses/P0_qq_zzqq/G1/results.dat
Survey return zero cross section.

I checked the list of possible reasons for the zero cross section, but none of them seem to apply. My run and param cards are just the default ones, so it can't be too stringent cuts.

Would you have an idea as to what could cause this or how I can proceed to debug ?

Hi Philip,

I suggest you go into

/ggZZ_loop_v2/SubProcesses/P0_qq_zzqq/G1/

and check the log files and report them (or at least the last 50 lines or so) here.
If you run:

../madevent < input_app.txt

you should see that it stops at some point with a zero cross-section. One can then investigate and see why it is so.

Hello Valentin,

we managed to debug the problem and have successfully generated a first gg > zz gg sample ! Thank you very much for your continuous support, I appreciate it a lot.

We will now go ahead and try to produce an MLM merged sample of gg > zz + (0, 1, 2 jets) to be used for the ZZ+jets study as well.

I am glad to hear that!

Notice that with MG5aMC v2.5.1beta2 (latest release, very soon to come out of beta), we have a streamlined interface to Pythia8 at LO (also applicable for loop-induced simulations) which now supports *both* MLM and CKKW-L merging.

On top of that, matching systematics can be computed online within Pythia8 (for both merging schemes) and the corresponding weights propagated in the analysis/ in the hepmc event record produced.

That could be useful in your case, since producing loop-induced parton-level events is very expensive.

Let me know if you have any problem/question on loop-induced event generation or on the merging strategies mentioned above.
(if your question pertains to merging, please open a new question thread with a corresponding title, so that the discussion can easily be searchable by other users with similar questions).