Comment 4 for bug 921487

Hi,

In fact, both Johan and I have created a fix for this problem.
So if you need this fix urgently you can use the current beta version:
lp:~maddevelopers/madgraph5/fix_fermion_order_interaction

(which is the Johan version).
Tommorow, I'll run an extensive test on that branch. to ensure that
this fix didn't breaks anything else.
If it passes, I will merge with my fix (which didn't cover all the
case, but avoid to use special routines in most of the case).

At that time, we will push that version as public.

So sorry to not have put any update on this topic, but behind the
scene, the work was done.

Cheers,

Olivier

On 31-janv.-12, at 04:32, Ben O'Leary wrote:

> more in-depth, thanks to Florian Staub:
>
> The result for a "diff -rq" between both created directory (for a
> positive and negative PDG of the chargino) looks like:
>
> ============
> ....
> Files dir_run_check_SA_posPDG//Source/DHELAS/aloha_file.inc and
> dir_run_check_SA_negPDG//Source/DHELAS/aloha_file.inc differ
> Only in dir_run_check_SA_negPDG//Source/DHELAS: FFS1C1_0.f
> Only in dir_run_check_SA_negPDG//Source/DHELAS: FFS1C1_2_0.f
> Only in dir_run_check_SA_negPDG//Source/DHELAS: FFS1C1_2_3.f
> Only in dir_run_check_SA_negPDG//Source/DHELAS: FFS1C1_3.f
> Only in dir_run_check_SA_negPDG//Source/DHELAS: FFS2C1_0.f
> Only in dir_run_check_SA_negPDG//Source/DHELAS: FFS2C1_3.f
> Files dir_run_check_SA_posPDG//SubProcesses/P0_ddx_x2mx2p/configs.inc
> and dir_run_check_SA_negPDG//SubProcesses/P0_ddx_x2mx2p/configs.inc
> differ
> ....
> ============
>
> So, it seems at first glance that Madgraph generates helicity
> amplitudes for the conjugated vertex. But, a comparison between
> FFS1C1_0.f and FFS1_0.f leads to
>
>
> =====
> < SUBROUTINE FFS1C1_0(F1,F2,S3,COUP,VERTEX)
> ---
>> SUBROUTINE FFS1_0(F1,F2,S3,COUP,VERTEX)
> ====
>
> So, it's just a renaming of the routines. In that way everything would
> be fine, if Madgraph would use always FFS1C1_0 and FFS1_0 and do no
> other changes. However, comparing the two files for the matrix
> elements (matrix.f), we see
>
> ==================
> 273,274c276,278
> < CALL FFS1_2_0(W(1,3),W(1,2),W(1,10),GC_3554,GC_3555,AMP(6))
> < CALL FFS1_2_3(W(1,1),W(1,4),GC_2344,GC_2345,MSU2, WSU2,
> W(1,11))
> ---
>> CALL FFS1C1_2_0(W(1,12),W(1,2),W(1,11),GC_3554,GC_3555,AMP(6))
>> CALL FFS1C1_2_3(W(1,3),W(1,10),GC_2344,GC_2345,MSU2, WSU2, W(1
>> $ ,13))
> 276,277c280,282
> ===================
>
> So, it uses the same expressions for the vertices (GC_3554, ...) in
> the amplitudes, but combines them with different W functions
> (momenta?). It might (?)
> by possible to recover the same result, if also the hermitian
> conjugated of the vertex is used (i.e. interchanging e.g. GC_3554 <=>
> GC_2345 and adding a complex conjugation, or something like that).
>
> --
> You received this bug notification because you are a member of
> MadTeam,
> which is the registrant for MadGraph5.
> https://bugs.launchpad.net/bugs/921487
>
> Title:
> cross-section highly dependent on convention for PDG particle code
>
> Status in The MadGraph Matrix Element Generator version 5:
> New
>
> Bug description:
>
> In the context of extended models with charged particles where one
> has to decide whether the particle with a negative electric charge
> gets a positive PDG code (like a tau') or a negative code (like
> another generation of chargino), or in the context of the MSSM
> without R-parity, where the 4th & 5th generations have the other
> sign for their code compared to the 1st 3 generations, it is very
> important that the cross-section does not depend on which way around
> the PDG code is chosen.
>
> MadGraph 5 (v1.3.30, at least) does not work properly in this
> context.
>
> The easiest way to show this is to do the following:
> 1) in MG5, do:
> import model mssm -modelname
> generate e+ e- > x1+ x1-
> output defaultMssmElectronPositronToCharginoPair
> exit
> 2) go to the mssm directory in MadGraph5_v1_3_30/models/ & delete
> all the .pyo files.
> 3) in that directory, edit particles.py by putting a '-' before
> "1000024" so that now the positive chargino has PDG code -1000024.
> 4) in MG5, do:
> import model mssm -modelname
> generate e+ e- > x1+ x1-
> output signSwappedElectronPositronToCharginoPair
> exit
> 5) copy an SLHA SPS1a spectrum to param_card.dat in both versions,
> & edit run_card.dat to make an ILC-like run, by changing lpp1 &
> lpp2 to 0 (so that MG doesn't look for the electron components of
> protons), & ebeam1 & ebeam2 to 500 each rather than the default
> 7000, & also reduce nevents to 1000 rather than the default 10000
> just to save a bit of time.
> 6) in defaultMssmElectronPositronToCharginoPair/, do ./bin/
> survey, ./bin/refine, & then ./bin/generate_events
> 7) repeat step 6 in signSwappedElectronPositronToCharginoPair/
> 8) marvel at how the default-sign version gives a cross-section of
> 0.14458 pb while merely swapping the sign of the PDG code gives
> 0.93335 pb.
> 9) check that the Feynman diagrams are really the same, noting that
> it's just which particle MG labelled as 3 or 4, & which way the
> arrows are pointing on the fermion lines.
>
> Since the UFO format cares about the PDG *only* to the extent that it
> is referred to as an index for the SLHA MASS block in parameters.py,
> the problem seems to be the way MG deals with fermion flow. I have
> read up on how it is described in section 2.2 of JHEP 1106(2011)128,
> and as far as I can see, the alogrithm _should_ work & give the same
> result either way. however, it obviously does not. the error on the
> cross-sections that MG quotes is about 0.3%. the contribution from
> each of the 3 diagrams is roughly the same, just each diagram
> produces
> ~6.5 more cross-section when the sign of the PDG code is swapped (not
> exactly the same factor, but I could believe that the differences are
> statistical), hence swapping the sign of the PDG code seems to
> generate ~6.5 times more cross-section per diagram, so maybe it's a
> normalization issue? one can check that the generated HELAS code
> really is different, but as far as I can tell it should be different,
> since it is working with the fermion-flow-conjugated vertices, though
> it should still produce exactly the same results for each case.
>
> Happy hunting,
> Ben
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/madgraph5/+bug/921487/+subscriptions