asymmetry in wbf jets

Bug #1123974 reported by Daniel Wiegand
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MadGraph5_aMC@NLO
Fix Released
Low
Johan Alwall

Bug Description

Hey guys,
when looking at the WBF-process p p > j j mu+ mu- /h QED=4 QCD=0 with a cut on the invariant muon mass between 118.4GeV and 121.6GeV (additionally to the standard cuts) one ends up with a cross-section several orders of magnitude below the corresponding SHERPA-result (0.33fb - which we confirmed to be right).
Furthermore if one looks into the pseudorapidity distribution of the two jets, one finds that they are not symmetric around eta=0, but that the leading jet prefers the negative and the second the jet accordingly the positive direction (i.e. hemisphere of the detector).

cheers
Daniel

Related branches

Changed in madgraph5:
assignee: nobody → Johan Alwall (johan-alwall)
Revision history for this message
Johan Alwall (johan-alwall) wrote :
Download full text (3.5 KiB)

Dear Daniel,

Thanks for your bug report and for providing details about your generation.

You are using a combination of several strong cuts:
1. VBF cuts (delta(eta) for the jets > 4.2 and mmjj > 500 GeV)
2. A very narrow range in M(mu+mu-) (mmll > 118.4 and mmllmax < 121.6)

In this case, there are a number of integration channels where the variables in the phase space parameterization are misaligned with the chosen cuts, which makes it very difficult for the integration routines to find any events that pass the cuts. In particular, integration channels corresponding to t-channel diagrams, i.e., where the two quark lines are emitting a vector boson (photon, Z or W) which in turn connect to a t-channel muon line, are not parameterized in terms of the invariant mass of the muons. So it is pure luck if these channels happen to find any events in the very narrow invariant mass range.

There is one type of channels that fail in your process, that we can actually fix. This is channels where the muon pair comes from an s-channel Z boson, which fail because we use a parameterization assuming that the Z can go onshell. This can be fixed by replacing line 469 in Template/SubProcesses/myamp.f,
               else if(iden_part(i).eq.0 .or. lbw(nbw).eq.1) then
by
               else if((prmass(i,iconfig)+5d0*prwidth(i,iconfig)).ge.xm(i)
     $ .and. iden_part(i).eq.0 .or. lbw(nbw).eq.1) then

This allows MadEvent to take into account an invariant mass cut above the peak range for s-channel resonances. This change has been done in the 1.5.8 branch, and will be released with that version. With this modification, your result becomes roughly half of the correct result, and the asymmetry almost disappears.

However, for some other types of integration diagrams (including the t-channel diagrams mentioned above), there is no way (within the present MadEvent phase space integration framework) to ensure that all channels can find events with such stringent cuts on the parton-level integration. In the MadEvent method (single diagram enhanced multichannel integration, see http://arxiv.org/abs/hep-ph/0208156), each channel j provides a fraction |M|^2*|A_j|^2/Sum(|A_i|^2) of the cross section. If some (non-negligible) channels fail to produce events due to too strong cuts, the cross section calculation is not complete. You might therefore get not only too small cross section, but also effects in the phase space distributions, including asymmetries like the one you describe in the eta distribution of the jets.

So in this case, the way to fix the problem is to increase the M(mu+mu-) range to be big enough that all channels find events in the appropriate region. With your other cuts unchanged, the range mmll=110, mmllmax=160 is enough. This still cuts out the Z peak, so you don't need to generate nearly as many events as you would have if you ran completely without mmll cut. You can then perform the remaining cut down to your narrow range 118.4-121.6 GeV in your analysis code.

So how does a user know in general if there might be a problem like this in a process? Basically, this might be a problem if you see integration channels that are zero although...

Read more...

Changed in madgraph5:
status: New → Fix Committed
Changed in madgraph5:
importance: Undecided → Low
Changed in madgraph5:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.