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
Well, since nobody form the MadGraph team seems to be working on this, I'll just post a little more information that I have gathered about this bug:
1) Um, I wasn't really thinking when I made the statement about "the contribution from each of the 3 diagrams", since there are clearly interference terms.
2) The interference terms seem to be the crucial part, since apparently the results are the same if one only considers one diagram at a time:
"generate e+ e- > a > x1+ x1- @1
add process e+ e- > z > x1+ x1- @2
add process e+ e- > x1+ x1- / a z @3
the results for each individual process is the same with or without the minus sign." (thanks to Florian Bonnet)
3) It may be that the problem is MG getting the helicities wrong inconsistently, because one can take just coherent sum of the photon & Z diagrams, & then the result does not depend on which sign of code the chargino has; however, in these diagrams, there are no clashing arrows of fermion flow.
4) Certainly one cannot state that it's just the result of a perverse choice of sign of code: if the down-antidown annihilation to charginos is correct, then the up-antiup equivalent has the problem, & vice-versa.
Maybe a little update from the MG team about the status of this bug would be appreciated? It's a rather serious issue: I'd like to be sure that all my cross-sections are not wrong by a factor of 6, & it has been almost a week since I reported this bug...
Thank you,
Ben