wiki:DevelopmentPage/MultiParton

Multi Parton Amplitudes

An effort should now be done to bring v5 towards handling multiparton processes. We are not aiming to a full MadEvent independent solution and we would be already happy if we could build a code that could run in a reasonable time for pp>V+5partons (so to do V+4 jets at NLO), pp>5 partons (so to do 4 jets at NLO). In fact, we are trying to get something working up to 1/Nc2 corrections (included). In this case we could go higher in multiplicity (up to pp> 7 partons so to do pp>6 jets at NLO).

The main line of optimization concerns multi-gluon amplitudes. At this stage we focus only on these. The reason is simple: once two quark lines are included then any other multi-quark subproc is suppressed in the number of colors and also kinematically (the latter is not a theorem but by experience it is true).

We suggest to proceeed in steps.

First Step : getting a code for pp>X + n gluons exact at all orders in 1/Nc and compiling.

This should be achieved rather easily, if we don't worry about SPEED (which we will in the next step, of course). Anyway is mandatory to have a code that can do |M|2 EXACTLY (at all orders in 1/Nc). Note that the current algorithm that gets the color matrix is already able to select powers in 1/Nc so this is not an issue.

In the attachment of this page, I have put an example of such a matrix.f, for gg>ggg, which I (Fabio) did by hand. It's very simple: the idea is that instead of writing down all the jamp's explicitly, we have one function that calculates one of them, given an order of the external gluons (let's say the identity order (1,2,3,...n) with n the number of gluons. In addition only the diagrams contributing to this jamp are calculated. At the end this is slower that the current way madgraph does because one ends up in calculating many times the same diagrams, i.e. this is inefficient. Note that a jamp is a color ordered amplitude and could be directly computed by mg5 by keeping the order of the gluons fixed in the diagrams.

Second Step : getting the code faster.

I believe the recalculation of the diagrams could be avoided with some clever caching, even though I am not sure how to do this in fortran. A better alternative is to use recursive Berends-Giele relations for color ordered amps. This is easy enough for pure gluonic amplitudes, which could be used to make tests. There is also another clear improvement that one could try to make, which is storing only one line of the color matrix and getting all the others by applying the same permutations.

Finally, if one is able to generate the permutations instead of listing them in the code, one could really write a small code: this is certainly possible (see attached file nexper.f for a fortran implementation), the problem is that we need exactly the same algo in Fortran (to run the code) and in Python (to write the code and make the identification of the jamp(i) with the corresponding element in the color matrix.

Third Step : Expand the results in powers of 1/Nc and MC over color flows

More about this to come...

Last modified 14 years ago Last modified on Mar 8, 2010, 3:25:29 PM

Attachments (2)

  • matrix2.f (21.7 KB ) - added by Fabio Maltoni 14 years ago. This is an example of a different format for matrix.f that wil allow compilation even for high multiplicities
  • nexper.f (2.2 KB ) - added by Fabio Maltoni 14 years ago. A routine to generate the next permutation

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.