MadGraph5_aMC@NLO

beam-electron energy in e-p collision

Asked by Sho Iwamoto

Hi MadTeam,

I am simulating an e-p collider and have encountered a problem, which is simply observed in the following procedure:

~~~
generate p e- > j ve
launch
parton
done
set lpp1 1
set lpp2 0
set ebeam 500
done
~~~

Then the generated file "unweighted_events.lhe.gz" has following <init>, which says the beam energy is 500.0000 GeV.
<init>
2212 11 5.000000e+02 5.000000e+02 0 0 247000 247000 -4 1
1.737900e+02 5.129000e-01 1.737900e+02 1
<generator name='MadGraph5_aMC@NLO' version='2.5.5'>please cite 1405.0301 </generator>
</init>
However, the electron energry in <event> tends to be larger than this beam energy:

<event>
 4 1 +1.7379000e+02 4.21935200e+01 7.54677100e-03 1.49266300e-01
        2 -1 0 0 501 0 +0.0000000000e+00 +0.0000000000e+00 +6.6401004881e+00 6.6401004881e+00 0.0000000000e+00 0.0000e+00 -1.0000e+00
       11 -1 0 0 0 0 -0.0000000000e+00 -0.0000000000e+00 -5.0000043526e+02 5.0000043526e+02 0.0000000000e+00 0.0000e+00 -1.0000e+00
        1 1 1 2 501 0 +7.0682493961e+00 +4.1597274055e+01 -7.4166341584e+01 8.5328421890e+01 0.0000000000e+00 0.0000e+00 -1.0000e+00
...

Here, the electron energy is 500.00043526 GeV.

Why does this happen? Physics, floating-number precision, or some bugs?

Additional notes:
  - This may be related to this question: https://answers.launchpad.net/mg5amcnlo/+question/268194 [NOTE ADDED: It is NOT related.]
  - This is not observed in ee colision.

Best,
Sho

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Olivier Mattelaer
Solved:
Last query:
Last reply:
Revision history for this message
Best Olivier Mattelaer (olivier-mattelaer) said : 		#1

Dear Sho,

This indeed seems related to numerical accuracy.
The reason of the problem is that we are evaluating the matrix element square in the rest-frame of the partonic system.
Then when we write the event, we have to boost each event in the lab-frame.

The "beta" of the boost can be compute from either the proton beam or the electron beam.
Looks like that the difference between those two is actually quite small:
0.99558186813982985 (computed from the proton)
 0.99558186030325391 (computed from the electron)
[more details for that particular event below]

The easiest to "hide" this problem is to flip the order of electron and proton in your process definition such that the boost will be performed for the electron allowing to push this numerical inaccuracy in the proton beam.

Cheers,

Olivier

details on the computation sketched above:
xbk(1) 2.2139606420729938E-003 m1 0.93799999999999994
 ( 10626.373003149523 10626.372961750450 ),->( 500.00000000000000 499.99912015522585 )
 beta for proton beam 0.99558186813982985
 xbk(2) 1.0000000000000000 m2 0.0000000000000000
 ( 23.526371596960047 -23.526371596960047 ),->( 500.00000000000000 -500.00000000000000 )
 beta from lepton 0.99558186030325391

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said : 		#2

For information,

I have change the code such that in future version of the code, I'm automatically use the lepton for such boost.

Cheers,

Olivier

=== modified file 'Template/LO/SubProcesses/unwgt.f'
--- Template/LO/SubProcesses/unwgt.f 2016-09-03 13:26:00 +0000
+++ Template/LO/SubProcesses/unwgt.f 2017-06-22 07:56:22 +0000
@@ -603,7 +603,7 @@
       if (nincoming.eq.2) then
          if (xbk(1) .gt. 0d0 .and. xbk(1) .le. 1d0 .and.
      $ xbk(2) .gt. 0d0 .and. xbk(2) .le. 1d0) then
- if(xbk(1).eq.1d0.or.pmass(1).eq.0d0) then
+ if(lpp(2).ne.0.and.(xbk(1).eq.1d0.or.pmass(1).eq.0d0)) then
                ! construct the beam momenta in each frame and compute the related (z)boost
                ebi(0) = p(0,1)/xbk(1) ! this assumes that particle 1 is massless or mass equal to beam
                ebi(1) = 0

Revision history for this message
Sho Iwamoto (misho) said : 		#3

Hi Olivier,

Thank you very much, it solved my problem.

Events with the electron harder than the beam are actually vetoed in showering stage, line 323 of pyremn.f (pythia6)
323 IF(PMIN(0)+PMIN(1)+PMIN(2).GT.VINT(1).OR.(MINT(45).GE.2.AND.
324 &PMIN(1).GT.PSYS(1,4)).OR.(MINT(46).GE.2.AND.PMIN(2).GT.
325 &PSYS(2,4))) THEN
because pythia thinks that its showering (ISR?) has a problem (or 'failure' in MC sense).

---
     Error type 9 has occured after 0 PYEXEC calls:
     (PYEVNW:) failed to evolve shower or multiple interactions. Returning.
---

Switching e <--> p makes the electron energy less than the beam energy (because floating point number precision) and now pythia-pgs correctly works.

Revision history for this message
Sho Iwamoto (misho) said : 		#4

Thanks Olivier Mattelaer, that solved my question.

Revision history for this message
Sho Iwamoto (misho) said : 		#5

Let me fix my last comment:
Switching e <--> p makes the electron energy *EQUAL TO* the beam energy and now pythia-pgs correctly works.