Merge lp:~maddevelopers/mg5amcnlo/labframe into lp:~maddevelopers/mg5amcnlo/LTS_dev

[Olivier Mattelaer]

pass to the real lab frame for the plot (was hadronic CM frame)

Dear Olivier,

I have modified the "madfks_plot.f" file in order to get momenta in the lab frame for plotting. Earlier it was calculated in the hadronic CM frame. Please have a look and let me know your opinions.

Regards,
Laboni

[Rikkert Frederix (frederix)]

Hi all,

Shouldn't this also be done for writing of the events (in MC@NLO mode)?

Best,
Rikkert

[Olivier Mattelaer (olivier-mattelaer)]

Hi Rik,

We actually do not know if MC@(N)LO does have that issue or not.
Manna will make the plot that make us discover the issue to check if we need it or not.
In the meantime, I have update this branch to have a candidate for such boost.

However, it is not 100% clear to me, how to handle those three functions:
put_on_MC_mshell_Hevin
put_on_MC_mshell_Hevout
put_on_MC_mshell_in

I have "corrected", put_on_MC_mshell_in
but the situation is quite "weird" for the two others. Can you comment on those functions?

Olivier

[lp:~maddevelopers/mg5amcnlo/labframe]

382. By olivier-mattelaer on 2022-02-24

better naming convention/text for FO boost

383. By olivier-mattelaer on 2022-02-24

add boost to labframe for aMC@NLO

[Stefano Frixione (stefano-frixione)]

Hi Olivier,
what are we talking about?
Those functions have been originally written by me. As far as I know,
they don't have bugs, so I don't know what you mean by "corrected".
What they do is to transform a massless-quark event into a massive-quark
one, by using the MC masses. This is essential for the MC to function
properly.
There is some arbitrariness on how one does this operation, and I'm
reluctant to contemplate changes (in the normal hadron-hadron operation
mode), unless they have a strong justification and are thoroughly tested,
Cheers, Stefano.

On Thu, 24 Feb 2022, Olivier Mattelaer wrote:

> Hi Rik,
>
> We actually do not know if MC@(N)LO does have that issue or not.
> Manna will make the plot that make us discover the issue to check if we need it or not.
> In the meantime, I have update this branch to have a candidate for such boost.
>
> However, it is not 100% clear to me, how to handle those three functions:
> put_on_MC_mshell_Hevin
> put_on_MC_mshell_Hevout
> put_on_MC_mshell_in
>
> I have "corrected", put_on_MC_mshell_in
> but the situation is quite "weird" for the two others. Can you comment on those functions?
>
> Olivier
> --
> https://code.launchpad.net/~maddevelopers/mg5amcnlo/labframe/+merge/415948
> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/LTS_dev.
>
>

[Olivier Mattelaer (olivier-mattelaer)]

Hi Stefano,

The original issue that we found/fixed is that for fixed order (both LO and NLO) the rapidity distribution were not in agreement with other codes when the two beams had asymmetric energies (i.e. the hadronic cm frame was not the lab frame).
Manna Laboni checked that the rapidity dstribution was actually plotted in the hadronic cm frame and not the lab frame.
And she proposed one additional boost before the plotting function to fix the issue.

Rikkert point out that one likely needs to implement a similar fix for aMC@(N)LO. We still need to double check that case but one can guess that it will suffer the same issue.

Now when looking at how one can implement the boost for aMC@NLO. I realised that the rapidity of a frame was also used in those three functions and for the third a clear warning was set that it should be the same rapidity as the one used to boost the event.

So what I mean by "corrected" is to modify the rapidity shift in "put_on_MC_mshell_in" to be consistent with the
additional boost used to write the events.

The situation for the two other function seems less clear to me.
They also use a shift in rapidity but computed in a different way (via ybst_til_tocm rather than via ybst_til_tolab variable).

So my question for you, is how can we check that those three functions are working correctly in presence of assymetric beams? (for the LHC, nothing will change actually) to be sure that the rapidity shift used in those function are fully consistent?

Thanks,

Olivier

> On 24 Feb 2022, at 15:45, Stefano Frixione <email address hidden> wrote:
>
> Hi Olivier,
> what are we talking about?
> Those functions have been originally written by me. As far as I know,
> they don't have bugs, so I don't know what you mean by "corrected".
> What they do is to transform a massless-quark event into a massive-quark
> one, by using the MC masses. This is essential for the MC to function
> properly.
> There is some arbitrariness on how one does this operation, and I'm
> reluctant to contemplate changes (in the normal hadron-hadron operation
> mode), unless they have a strong justification and are thoroughly tested,
> Cheers, Stefano.
>
>
>
> On Thu, 24 Feb 2022, Olivier Mattelaer wrote:
>
>> Hi Rik,
>>
>> We actually do not know if MC@(N)LO does have that issue or not.
>> Manna will make the plot that make us discover the issue to check if we need it or not.
>> In the meantime, I have update this branch to have a candidate for such boost.
>>
>> However, it is not 100% clear to me, how to handle those three functions:
>> put_on_MC_mshell_Hevin
>> put_on_MC_mshell_Hevout
>> put_on_MC_mshell_in
>>
>> I have "corrected", put_on_MC_mshell_in
>> but the situation is quite "weird" for the two others. Can you comment on those functions?
>>
>> Olivier
>> --
>> https://code.launchpad.net/~maddevelopers/mg5amcnlo/labframe/+merge/415948
>> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/LTS_dev.
>>
>>
>
> --
> https://code.launchpad.net/~maddevelopers/mg5amcnlo/labframe/+merge/415948 <https://code.launchpad.net/~maddevelopers/mg5amcnlo/labframe/+merge/415948>
> You proposed lp:~maddevelop...

[Stefano Frixione (stefano-frixione)]

Hi Olivier,

> The original issue that we found/fixed is that for fixed order (both LO
> and NLO) the rapidity distribution were not in agreement with other
> codes when the two beams had asymmetric energies (i.e. the hadronic cm
> frame was not the lab frame).
well of course: for all applications so far, the hadronic cm is the
lab frame. The code has been constructed with LHC and Tevatron in mind;
at the NLO, at least.

> And she proposed one additional boost before the plotting function to
> fix the issue.
Well, I guess there's no fixing here: one gets what one asks for, which
is any observable in the hadronic cm. Having obtained that, the observable
in another frame can be obtained by boosting which, in the case of
rapidity, is particularly simple.

> Now when looking at how one can implement the boost for aMC@NLO. I
> realised that the rapidity of a frame was also used in those three
> functions and for the third a clear warning was set that it should be
> the same rapidity as the one used to boost the event.
NLO/MC@NLO uses extensively event projection, which in turn is based
on hadronic beams being back to back (and of equal energy, although I
suppose the latter condition can be relaxed).

> So what I mean by "corrected" is to modify the rapidity shift in
> "put_on_MC_mshell_in" to be consistent with the additional boost used to
> write the events.
>
> The situation for the two other function seems less clear to me. They
> also use a shift in rapidity but computed in a different way (via
> ybst_til_tocm rather than via ybst_til_tolab variable).
>
> So my question for you, is how can we check that those three functions
> are working correctly in presence of assymetric beams? (for the LHC,
> nothing will change actually) to be sure that the rapidity shift used in
> those function are fully consistent?
The answer to this might be difficult: it requires reconsidering the
various derivations, and (because of the recent work on e+e- at the NLO)
I can't find all of my notes, which I have probably lost at this point.

It seems to me that the easiest solution is that of performing a boost
after all the computations are finished: that boost depends solely on
your lab frame and the beam kinematics in that frame.

Cheers, Stefano.

>
> Thanks,
>
> Olivier
>
>
>
>
>
>
>
>
>
>
>
>
>> On 24 Feb 2022, at 15:45, Stefano Frixione <email address hidden> wrote:
>>
>> Hi Olivier,
>> what are we talking about?
>> Those functions have been originally written by me. As far as I know,
>> they don't have bugs, so I don't know what you mean by "corrected".
>> What they do is to transform a massless-quark event into a massive-quark
>> one, by using the MC masses. This is essential for the MC to function
>> properly.
>> There is some arbitrariness on how one does this operation, and I'm
>> reluctant to contemplate changes (in the normal hadron-hadron operation
>> mode), unless they have a strong justification and are thoroughly tested,
>> Cheers, Stefano.
>>
>>
>>
>> On Thu, 24 Feb 2022, Olivier Mattelaer wrote:
>>
>>> Hi Rik,
>>>
>>> We actually do not know if MC@(N)LO does have that issue or not.
>>> Manna will make the plot that make us d...

Unmerged revisions

383. By olivier-mattelaer on 2022-02-24

add boost to labframe for aMC@NLO

382. By olivier-mattelaer on 2022-02-24

better naming convention/text for FO boost

381. By Laboni Manna on 2022-02-18

pass to the real lab frame for the plot (was hadronic CM frame)

=== modified file 'Template/NLO/SubProcesses/add_write_info.f'
--- Template/NLO/SubProcesses/add_write_info.f	2017-06-15 16:22:23 +0000
+++ Template/NLO/SubProcesses/add_write_info.f	2022-02-24 14:06:03 +0000
@@ -1,4 +1,4 @@
-      subroutine add_write_info(p_born,pp,ybst_til_tolab,iconfig,Hevents
+      subroutine add_write_info(p_born,pp,ybst_til_cmhadron,iconfig,Hevents
      &     ,putonshell,ndim,x,jpart,npart,pb,shower_scale)
 c Computes all the info needed to write out the events including the
 c intermediate resonances. It also boosts the events to the lab frame
@@ -13,7 +13,7 @@
 
 c Arguments
       double precision p_born(0:3,nexternal-1),pp(0:3,nexternal)
-      double precision ybst_til_tolab,shower_scale
+      double precision ybst_til_cmhadron,shower_scale
       integer iconfig
       logical Hevents,putonshell
       integer ndim,jpart(7,-nexternal+3:2*nexternal-3),npart
@@ -28,6 +28,7 @@
       logical firsttime,firsttime2
       data firsttime/.true./
       data firsttime2/.true./
+      double precision ybst_til_tolab
 
 c The process chosen to write
       integer i_process_addwrite
@@ -402,7 +403,7 @@
 c Set-up the external momenta that should be written in event file
 c Also boost them to the lab frame.
 c
-      if (abs(ybst_til_tolab).le.1d-7) then
+      if (abs(ybst_til_cmhadron).le.1d-7) then
          do i=1,nexpart
             do j=0,3
                if (Hevents) then
@@ -418,10 +419,11 @@
             endif
          enddo
       else
-         chy=cosh(ybst_til_tolab)
-         shy=sinh(ybst_til_tolab)
+         chy=cosh(ybst_til_cmhadron)
+         shy=sinh(ybst_til_cmhadron)
          chymo=chy-1d0
          do i=1,nexpart
+c           boost the momenta to the  Hadronic CM frame from partonic CM frame:            
             if (Hevents) then
                call boostwdir2(chy,shy,chymo,xdir,
      &              pp(0,i),p1(0,i))
@@ -429,6 +431,14 @@
                call boostwdir2(chy,shy,chymo,xdir,
      &              p_born(0,i),p1(0,i))
             endif
+c     boost the momenta to the lab frame from Hadronic CM frame :
+            if (ebeam(1).ne.ebeam(2))then
+              ybst_til_tolab = 0.5*log((ebeam(2))/(ebeam(1))) ! boost function 
+              chy=cosh(ybst_til_tolab)
+              shy=sinh(ybst_til_tolab)
+              chymo=chy-1.d0
+              call boostwdir2(chy,shy,chymo,xdir,p1(0,i),p1(0,i))
+           endif
             do j=0,3
                pb(j,i)=p1(j,i)
             enddo
@@ -1213,6 +1223,7 @@
       subroutine put_on_MC_mshell_in(p,xm1,xm2,mfail)
       implicit none
       include 'nexternal.inc'
+      include 'run.inc'
       double precision p(0:3,nexternal),xm1,xm2
       integer mfail
       double precision xm1_r,xm2_r
@@ -1222,6 +1233,9 @@
      #                        sqrtshat,shat
       double precision xmcmass(nexternal)
       common/cxmcmass/xmcmass
+
+      double precision ycm
+      
 c
       if (p(0,1).lt.0d0) then
          mfail=1
@@ -1240,8 +1254,13 @@
       xm1_r=xm1
       xm2_r=xm2
 c$$$CHECK AGAIN USE OF ybst_til_tolab IN getxmss.
-c$$$MUST BE THE SAME BOOST AS WHEN WRITING EVENTS
-      call getxmss_madfks(shat,ybst_til_tolab,
+c$$$  MUST BE THE SAME BOOST AS WHEN WRITING EVENTS
+      ycm = ybst_til_tolab
+      if (ebeam(1).ne.ebeam(2))then
+         ycm = ycm + 0.5*log((ebeam(2))/(ebeam(1)))
+      endif
+      
+      call getxmss_madfks(shat,ycm,
      #                    p(3,1),xm1_r,p(3,2),xm2_r,
      #                    p(3,1),p(3,2),mfail)
       if(mfail.eq.0)then

=== modified file 'Template/NLO/SubProcesses/madfks_plot.f'
--- Template/NLO/SubProcesses/madfks_plot.f	2017-06-15 19:31:40 +0000
+++ Template/NLO/SubProcesses/madfks_plot.f	2022-02-24 14:06:03 +0000
@@ -213,36 +213,40 @@
       end
 
 
-      subroutine outfun(pp,ybst_til_tolab,www,iPDG,itype)
+      subroutine outfun(pp,ybst_til_hadroncm,www,iPDG,itype)
 C
 C *WARNING**WARNING**WARNING**WARNING**WARNING**WARNING**WARNING**WARNING*
 C
 C In MadFKS, the momenta PP given in input to this function are in the
 C reduced parton c.m. frame. If need be, boost them to the lab frame.
-C The rapidity of this boost is
+C The rapidity of the boost to hadronic CM frame is 
 C
-C       YBST_TIL_TOLAB
+C       YBST_TIL_hadroncm
 C
 C also given in input
 C
 C This is the rapidity that enters in the arguments of the sinh() and
 C cosh() of the boost, in such a way that
-C       ylab = ycm - ybst_til_tolab
-C where ylab is the rapidity in the lab frame and ycm the rapidity
+C       ylab = ycm - ybst_til_hadroncm
+C     where ylab is the rapidity in the hadronic center of mass frame
+C      and ycm the rapidity
 C in the center-of-momentum frame.
 C
+C     If the hadronic center of mass frame is not the same as the lab frame
+C     then a second boost is done to move to the lab frame      
 C *WARNING**WARNING**WARNING**WARNING**WARNING**WARNING**WARNING**WARNING*
       use extra_weights
       implicit none
       include 'nexternal.inc'
       include 'run.inc'
       include 'genps.inc'
-      double precision pp(0:3,nexternal),ybst_til_tolab
+      double precision pp(0:3,nexternal),ybst_til_hadroncm
       integer itype
       double precision p(0:4,nexternal),pplab(0:3,nexternal),chybst
      $     ,shybst,chybstmo
       integer i,j,ibody,i_wgt,ii,jj,kk,n,nn
       double precision xd(3)
+      double precision ybst_til_tolab
       data (xd(i),i=1,3) /0d0,0d0,1d0/
       integer istatus(nexternal),iPDG(nexternal)
       double precision pmass(nexternal)
@@ -265,13 +269,23 @@
          write(*,*)'Error in outfun: unknown itype',itype
          stop
       endif
-c Boost the momenta to the lab frame:
-      chybst=cosh(ybst_til_tolab)
-      shybst=sinh(ybst_til_tolab)
+c Boost the momenta to the hadronic CM frame:
+      chybst=cosh(ybst_til_hadroncm)
+      shybst=sinh(ybst_til_hadroncm)
       chybstmo=chybst-1.d0
       do i=1,nexternal
          call boostwdir2(chybst,shybst,chybstmo,xd,pp(0,i),pplab(0,i))
       enddo
+      if (ebeam(1).ne.ebeam(2))then
+c boost the momenta to the lab frame from Hadronic CM frame :
+        ybst_til_tolab = 0.5*log((ebeam(2))/(ebeam(1))) ! boost from CM hadron to lab frame
+        chybst=cosh(ybst_til_tolab)
+        shybst=sinh(ybst_til_tolab)
+        chybstmo=chybst-1.d0
+        do i=1,nexternal
+         call boostwdir2(chybst,shybst,chybstmo,xd,pplab(0,i),pplab(0,i))
+        enddo
+      endif
 c Fill the arrays (momenta, status and PDG):
       do i=1,nexternal
          if (i.le.nincoming) then