Pseudorapidity cut of charged leptons

Hi,

You have to understand that such cut is not to always going to work. The reason is that madgraph use a lot of optimization to speed up the computation and that your cut is not compatible with such optimization.
They are two optimization that you have to ask madgraph to not use:
1) beam symmetry (u u~ process is the same as u~ u)
2) lepton symmetry (optimization e- and mu-)

To remove the first and at least partly the second, you have to generate the code sith
set group_subprocesses False
Depending of your process, madgraph might still use some optimization on lepton. In that case you also need to ensure that at least the muon is massive.

After all that, you should be able to distinguish electron for muon,
At that stage the easiest is to have a different file dummy_fct.f for the directory with electron and muon.

Otherwise, you have to split the is_a_l option in two sub-gategory (but this can means change plenty of files).

Cheers,

Olivier

Dear Olivier,

First of all, I am making all these modification to calculate backward and forward asymmetry (A_FB) in Z-> ll decays. I generate two event files: 1) one for positively charged lepton in the eta > 0 plane 2) one for positively charged lepton in the eta < 0 plane. I split the is_a_l option in two sub-category as you suggested. First I add the following lines in setcuts.f:

         if ((idup(i,1,iproc)).eq.-11) is_a_lp(i)=.true. ! e+
         if ((idup(i,1,iproc)).eq.-13) is_a_lp(i)=.true. ! mu+

Then I add the following lines in cuts.f to constrain the positively charged lepton in the eta>0 plane and generate events for p p > l+ l- (the first event file):

c Rapidity min & max cuts
c
      do i=nincoming+1,nexternal
         if(debug) write (*,*) 'abs(rap(',i,'))=',abs(rap(p(0,i))),' ',etamin(i),':',etamax(i)
         notgood=(etamax(i).ge.0.and.abs(rap(p(0,i))) .gt. etamax(i)).or.
     & (abs(rap(p(0,i))) .lt. etamin(i))
         if (notgood) then
            if(debug) write (*,*) i,' -> fails'
            passcuts=.false.
            return
         endif
         if(is_a_lp(i)) then ! Added by Ozer
            if((rap(p(0,i))).lt.0) then ! Added by Ozer
                passcuts=.false. ! Added by Ozer
                return ! Added by Ozer
            endif ! Added by Ozer
         endif ! Added by Ozer
      enddo

Then, I change the line above "if((rap(p(0,i))).lt.0)" with "if((rap(p(0,i))).gt.0)" to constrain the positively charged lepton in the eta< 0 plane, and generate events using the same seed number (which gives me the second event file). After combining and analyzing these two event files, I can say that the LO calculations for backward-forward asymmetry is in "good" agreement with experimental measurements. However, when I use the same "trick" to calculate A_FB at NLO, A_FB only fluctuates around zero for the entire M_ll region, which shouldn’t be the case. Here is the lines that I added in cuts.f for NLO calculations (the functions is_a_lp and is_a_lm are already default at NLO.)

c pseudo-rapidity
            if (etal.gt.0d0) then
               if (abs(eta_04(p_reco(0,i))).gt.etal) then
                  passcuts_user=.false.
                  return
               endif
            endif
c Added by Ozer
            if(is_a_lp(i)) then
               if((eta_04(p_reco(0,i))).lt.0.) then
                  passcuts_user=.false.
                  return
               endif
            endif

Am I missing something here? Given that the shape of the eta distributions are completely different for LO and NLO calculations, could there be a profound reason why my "trick" does not work for NLO processes? Thanks.

Cheers,
Ozer

Hi,

If you generate two files anyway, why not running your analysis/selection on the file generated without any cuts?
This will simplify a lot the generation and would allow to run MG5aMC with all the optimization activated rather than having to deactivate them all one by one.

The fact that you have fluctuation close to zero is a clear indication that you have a beam symmetry that prevent you from doing what you are doing. I actually do not know how to prevent it.

Cheers,

Olivier

Hi,

As you know, a forward-backward asymmetry is defined as AFB=(NF-NB)/(NF+NB), where NF is the number of events with the final state particle moving "forward" (i.e. eta(l+)>0) while NB is the number of events with the final state particle moving "backward" (i.e. eta(l+)<0). I want to calculate the NB using the same pseudorandom numbers that I use for NF . That way, I won't need to generate a gigantic number of events to compute AFB precisely.

In fact, the LO calculations also fluctuate close to zero if I run my analysis/selection on the file generated without any cuts. In other words, I would have to generate a lot of events for a precise result. We don't want to do this.

Then how come a beam symmetry prevents me from what I am doing only at NLO but it does not at LO ?

Cheers,

Ozer

Hi,

> I want to calculate the NB using the same pseudorandom numbers that I
> use for NF . That way, I won't need to generate a gigantic number of
> events to compute AFB precisely.

Such technique is not possible in MG5aMC.
The set of pseudo-randon number generator will not be the same between the two sample due to
the fact that the code auto-adapt to your cut. For your method to work you will have to fully change the code.

> In other
> words, I would have to generate a lot of events for a precise result. We
> don't want to do this.

I would rather suggest to use a re-weighting method to achieve your goal.

Cheers,

Olivier

> On 10 Oct 2020, at 01:35, Özer Özdal <email address hidden> wrote:
>
> Question #691392 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/691392
>
> Status: Answered => Open
>
> Özer Özdal is still having a problem:
> Hi,
>
> As you know, a forward-backward asymmetry is defined as AFB=(NF-
> NB)/(NF+NB), where NF is the number of events with the final state
> particle moving "forward" (i.e. eta(l+)>0) while NB is the number of
> events with the final state particle moving "backward" (i.e. eta(l+)<0).
> I want to calculate the NB using the same pseudorandom numbers that I
> use for NF . That way, I won't need to generate a gigantic number of
> events to compute AFB precisely.
>
> In fact, the LO calculations also fluctuate close to zero if I run my
> analysis/selection on the file generated without any cuts. In other
> words, I would have to generate a lot of events for a precise result. We
> don't want to do this.
>
> Then how come a beam symmetry prevents me from what I am doing only at
> NLO but it does not at LO ?
>
> Cheers,
>
> Ozer
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Olivier,

As you suggest, I will use a re-weighting method to achieve my goal. I will generate events for only one hemisphere, and then use a matrix element reweighting to extract the corresponding events on the other hemisphere. I should derive eta using the four momenta (for each event), change its sign, and then reevaluate the momenta by computing the two matrix elements. Does it sound similar to what you have in your mind ? If yes and possible, can you briefly explain how I can achieve this on MadGraph ? Thanks in advance.

Cheers,

Ozer

Hi,

> As you suggest, I will use a re-weighting method to achieve my goal. I
> will generate events for only one hemisphere, and then use a matrix
> element reweighting to extract the corresponding events on the other
> hemisphere.

I do not think that you need to generate events for only one hemisphere.
Do you have a reason for doing that?

> and then use a matrix
> element reweighting to extract the corresponding events on the other
> hemisphere. I should derive eta using the four momenta (for each event),
> change its sign, and then reevaluate the momenta by computing the two
> matrix elements. Does it sound similar to what you have in your mind ?

I would have just apply a pz -> -pz symmetry which I guess should do the trick.
But I did not think about the difference too much.
But for the rest, yes this is what I would have suggest.

> If yes and possible, can you briefly explain how I can achieve this on
> MadGraph ? Thanks in advance.

This is a perfect case for a reweighting PLUGIN. For this you obviously need to be quite expert in
Python and in Object Oriented Object.
If you are, then it should be simple to
1) look at this page where it explains the main mechanism for PLUGIN extension
((but does not cover reweighting plugin explicitly)
2) look at maddm project where they do use a PLUGIN for the re-weighting module.
3) your plugin has to change the definition of the weight such that the set of momenta of the
numerator and of the denominator are not the same. (so likely one function to change)

Cheers,

Olivier

> On 13 Oct 2020, at 21:45, Özer Özdal <email address hidden> wrote:
>
> Question #691392 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/691392
>
> Status: Answered => Open
>
> Özer Özdal is still having a problem:
> Hi Olivier,
>
> As you suggest, I will use a re-weighting method to achieve my goal. I
> will generate events for only one hemisphere, and then use a matrix
> element reweighting to extract the corresponding events on the other
> hemisphere. I should derive eta using the four momenta (for each event),
> change its sign, and then reevaluate the momenta by computing the two
> matrix elements. Does it sound similar to what you have in your mind ?
> If yes and possible, can you briefly explain how I can achieve this on
> MadGraph ? Thanks in advance.
>
> Cheers,
>
> Ozer
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.