MadGraph5_aMC@NLO

python standalone amplitude problem

Asked by rbalgc

Dear MG5 team,

I've found a strange behaviour when using the standalone amplitude of e-e+ > mu-mu+ process in Python.

After obtaining the amplitude for the e-e+ > mu-mu+ process as described in https://cp3.irmp.ucl.ac.be/projects/madgraph/wiki/FAQ-General-4 I was comparing the expression with my own amplitude when I found the following unexpected behaviour:
When evaluating the amplitude at the point

P = array([[ 499.514114491133, 499.982026313655, 499.957364866249, 499.538775938538],
       [ 0.007065503628, -0.007065503628, 52.232295778412, -52.232295778412],
       [ -0.093451344218, -0.093451344218, 99.631323373714, -99.81822606215 ],
       [ 499.514114491133, -499.982026313655, -487.137313442112, 486.66940161959 ]])

using "allmatrix2py.smatrixhel([11,-11,13,-13], -1, P, 0, 0, -1)" I obtain the value 0.007182568252776473. This is indeed the value I was expecting, but then evaluating the amplitude at

array([[ 499.5141144911327, 499.9820263136546, 499.9573648662495, 499.5387759385378],
       [ 0.007065503628 , -0.007065503628 , 52.2322957784124, -52.2322957784124],
       [ -0.0934513442182, -0.0934513442182, 99.6313233737138, -99.8182260621502],
       [ 499.5141144911327, -499.9820263136545, -487.1373134421117, 486.6694016195898]])

the value I obtained from MadGraph is 554921.7948358674

This makes no sense to me since both points are exactly the same, just with different precision.

I have tried the latest version (3.4.1) and the result is the same. Is this a known problem? Is there a way to avoid it?
Thank you

Question information

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

Looks like this is related to python since the fortran code does not seems affected...

This is weird and I'm looking at it,
This being said, your momenta do not have the same mass as the one set within the model so this might be a source of concern/inconsistency (but I doubt that this is the cause here since it should then occur for both fortran and python code)

I will update here when I find something.

Cheers,

Olivier

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

Ok,

I correct myself, my test in fortran was using a single precision variable and therefore the issue did not show up.
when carefully enter all number as double precision, I do have the same issue.

Olivier

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

So the issue is within this code:

 if(p(1).eq.0d0.and.p(2).eq.0d0.and.p(3).lt.0d0) then
            sqp0p3 = 0d0
         else
            sqp0p3 = dsqrt(max(p(0)+p(3),rZero))*nsf
         end if
         chi(1) = dcmplx( sqp0p3 )
         if ( sqp0p3.eq.rZero ) then
            chi(2) = dcmplx(-nhel )*dsqrt(rTwo*p(0))
         else
            chi(2) = dcmplx( nh*p(1), p(2) )/sqp0p3
         endif

In the first case, you do have
 sqp0p3 = 0.0000000000000000
and in the second you do have
sqp0p3=3.3717478808715228E-007

and due to that the helicity representation of the particle are quite different and lead to the different result.

So this is a clear numerical issue problem.

Now the fact that all your initial momenta have non zero virtuality (which they should) makes difficult to advance further.
I do see that your virtuality (actually for all particle is at the level of 9e-2) which is at the same level of the px/py value.
and If I hardcode them to 0 then the problem also disappear.

Cheers,

Olivier

Revision history for this message
rbalgc (rbalgc) said : 		#4

Ok, so the problem is only because the particles are not on-shell, right?

Thank you very much.

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

"Only" I do not know but this seems the main problem here.