MadGraph5_aMC@NLO

What is the connection between integration channels and diagrams in MadGraph 5?

Asked by Arian Abrahantes

Hello MG-Team:

First of all congratulations for such a great work with the new version this is really an optimized one

I usually run MG in batch mode. I am upgrading my scripts to work with MG5. I found a couple of issues that changed with respect to MG4 and I have some probably naive some requests.

I do cross section calculation for a given reaction and store separately: total cross section; x-section per process starter; and per Graph.

First the issue: The Graph numbering is hard to guess in MG5.1.4.1. A simple example if gluons produce a pair of gluinos is simple G1 is s-diagram and G2 t-diagrams but for quarks as starter the numbering in the matrix.ps is from 1 to 5 but in the HTML goes, of course, to values higher. Secondly suppose I force gluino to decay the graph number will increase. Which is the logic I should use here.

The request comes from the fact that in the web interface appears the x-section and its errors per graph. In general such results is the summation of multiruns, by looking into the code values on the HTML are calculated on the fly (in the examle above in my machine there are 10 processes to complete the gg t-diagram , ) Is there a chance to have such final result of the cross section at graph level in a separate file like the usual "results.dat", it would be only written in the "main directory of the multirun".

Regarding my request of course I could always make a grep on the HTML but I believe at some point I might end with units problems (passing from pb to fb etc) depending the visualization mode set by the developer (I crossed with this issue already in MG4).

Thank you very much for listening and any help in welcome,

arian

Question information

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

Hi,

In fact they are no one to one link between the diagram and the channel of integration (quote G).
Each G corresponds to a channel of integration this means to a different peak structure of the integrand (looks to the madevent paper for more information).

So I would say that those information shouldn't be use in any analysis since
1) Those number are not gauge invariant
2) Those number are not really the contribution of one diagram.

Having those in the html is in this case helpfull for debugging and to fastly identify which channel is unstable and creates trouble for the computation of the cross-section.

In fact I remove those files results.dat on the flight as soon as the information is read for the html output.
The reason to doing it to avoid too have too many small file on the disk (We have problem on our cluster since the number of small file is quite huge).

Now if you have a good reason to look at this information, I can add an option to preserve those files.
(Or you can just comment the rm of those files)
line 2177 of the file madgraph/interface/madevent_interface.py
(or ./bin/internal//madevent_interface.py in the output directory)

Cheers,

Olivier

Revision history for this message
Arian Abrahantes (arian-abrahantes) said : 		#2

hi olivier and thanks I will check ME reference. and actually there might b
some nstability in my calculation. There are too many diagrams becase final
state of the gluino decay triple decay is actually large.

thanks again,

cheers,

arian

no more to say

On Fri, Feb 10, 2012 at 5:35 PM, Olivier Mattelaer <
<email address hidden>> wrote:

> Your question #187387 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/187387
>
> Olivier Mattelaer posted a new comment:
> Hi,
>
> In fact they are no one to one link between the diagram and the channel of
> integration (quote G).
> Each G corresponds to a channel of integration this means to a different
> peak structure of the integrand (looks to the madevent paper for more
> information).
>
> So I would say that those information shouldn't be use in any analysis
> since
> 1) Those number are not gauge invariant
> 2) Those number are not really the contribution of one diagram.
>
> Having those in the html is in this case helpfull for debugging and to
> fastly identify which channel is unstable and creates trouble for the
> computation of the cross-section.
>
> In fact I remove those files results.dat on the flight as soon as the
> information is read for the html output.
> The reason to doing it to avoid too have too many small file on the disk
> (We have problem on our cluster since the number of small file is quite
> huge).
>
> Now if you have a good reason to look at this information, I can add an
> option to preserve those files.
> (Or you can just comment the rm of those files)
> line 2177 of the file madgraph/interface/madevent_interface.py
> (or ./bin/internal//madevent_interface.py in the output directory)
>
> Cheers,
>
> Olivier
>
> --
> You received this question notification because you asked the question.
>

Revision history for this message
Best Johan Alwall (johan-alwall) said : 		#3

Hello Arian,

In MadGraph 5, the phase space structures ("diagrams") of multiple subprocesses (matrix elements) are in general combined in each integration channels, which speeds up the code considerably compared to the MadGraph 4 treatment where each subprocess had its own directory for integration. You can find more details about this in the MadGraph 5 release paper. So the numbering of the channels is no longer, as you have noticed, directly associated with the diagram numbers. However, there is still a direct coupling between diagrams and channels. This coupling is given by the config_subproc_map.inc file and the symfact.dat files. Take as an example the process p p > j j, and the subprocess directory P0_qq_qq. This directory combines all processes q q > q q, i.e., u u > u u, u u~ > u u~, u u~ > d d~, etc. Each process (matrix element) corresponds to a matrix.f file, according to the order given in processes.dat:

1 u u > u u,c c > c c,d d > d d,s s > s s
mirror none
2 u u~ > u u~,c c~ > c c~,d d~ > d d~,s s~ > s s~
mirror u~ u > u u~,c~ c > c c~,d~ d > d d~,s~ s > s s~
3 u~ u~ > u~ u~,c~ c~ > c~ c~,d~ d~ > d~ d~,s~ s~ > s~ s~
mirror none
4 u c > u c,u d > u d,u s > u s,c d > c d,c s > c s,d s > d s
mirror c u > u c,d u > u d,s u > u s,d c > c d,s c > c s,s d > d s
5 u u~ > c c~,u u~ > d d~,u u~ > s s~,c c~ > u u~,c c~ > d d~,c c~ > s s~,d d~ > u u~,d d~ > c c~,d d~ > s s~,s s~ > u u~,s s~ > c c~,s s~ > d d~
mirror u~ u > c c~,u~ u > d d~,u~ u > s s~,c~ c > u u~,c~ c > d d~,c~ c > s s~,d~ d > u u~,d~ d > c c~,d~ d > s s~,s~ s > u u~,s~ s > c c~,s~ s > d d~
6 u c~ > u c~,u d~ > u d~,u s~ > u s~,c u~ > c u~,c d~ > c d~,c s~ > c s~,d u~ > d u~,d c~ > d c~,d s~ > d s~,s u~ > s u~,s c~ > s c~,s d~ > s d~
mirror c~ u > u c~,d~ u > u d~,s~ u > u s~,u~ c > c u~,d~ c > c d~,s~ c > c s~,u~ d > d u~,c~ d > d c~,s~ d > d s~,u~ s > s u~,c~ s > s c~,d~ s > s d~
7 u~ c~ > u~ c~,u~ d~ > u~ d~,u~ s~ > u~ s~,c~ d~ > c~ d~,c~ s~ > c~ s~,d~ s~ > d~ s~
mirror c~ u~ > u~ c~,d~ u~ > u~ d~,s~ u~ > u~ s~,d~ c~ > c~ d~,s~ c~ > c~ s~,s~ d~ > d~ s~

(All processes in each of the 7 subprocesses (and their mirror processes, i.e., with exchange of the initial state particles) have identical matrix elements, and are represented by a single matrix.f file).

 The connection between the diagrams of the processes and the integration channels is given by config_subproc_map.inc:

      DATA (CONFSUB(I,1),I=1,7)/1,2,1,1,0,1,1/
      DATA (CONFSUB(I,2),I=1,7)/2,0,2,0,0,0,0/
      DATA (CONFSUB(I,3),I=1,7)/0,1,0,0,1,0,0/

The columns are subprocesses, and the rows give the channels, while the numbers are the diagrams. So channel 1 (G1) corresponds to the 1st diagrams in subprocess 1, 2nd in subprocess 2, etc. Finally, there are diagrams that have symmetric divergency structures when you make a permutation of final-state particles. An example here is diagram 1 and 2, which correspond to the t- and u-channel diagram in u u > u u respectively. MadGraph recognizes this symmetry, and combines also these symmetric channels, so you will find only 2 integration channels in this subprocess directory, G1 and G3. These symmetric channels are given by the file symfact.dat, in this case:

 1 1
 2 -1
 3 1

The "-1" after the 2 means that channel 2 is combined with channel 1. The corresponding permutations is given by the file symperms.inc.

If you are wondering which contribution each subprocess and permutation gives to a given channel, this info is given in the G*/log.txt files. Take G1 as an example. After each iteration, the relative weights are written out for each contributing process and each permutation:
...
Relative summed weights:
  0.2561E-01 0.0000E+00 0.1052E+00 0.6983E-01 0.8473E-02 0.0000E+00 0.1188E+00 0.1208E+00 ...
  0.5452E-01 0.0000E+00 0.0000E+00 0.0000E+00 0.1091E-01 0.0000E+00 0.0000E+00 0.0000E+00 ...
...
There are 14 entries in each row, corresponding to the 7 processes and their mirror processes (proc1 mirror1 proc2 mirror2 etc). The rows correspond to the permutation channels.

In fact, this post is the most thorough (technical) documentation of the inner workings of the new channel structure of MadGraph 5, so I will change the name of this question to make it easier for other users to find it. Hope it helps.

All the best,
Johan

Revision history for this message
Arian Abrahantes (arian-abrahantes) said : 		#4

Thanks Johan Alwall, that solved my question.

Revision history for this message
Anna Elizabeth Woodard (annawoodard) said : 		#6

Hi experts,

I'm adding to this question because mine is related. Thanks for the explanation of the mapping between graphs and diagrams. I am running with this model [1] and I find that your explanation holds as long as I am not looking at any diagrams with NP vertices. As an example, here is a subprocess map (from [2]):

      DATA (CONFSUB(I,1),I=1,2)/1,1/
      DATA (CONFSUB(I,2),I=1,2)/2,2/
      DATA (CONFSUB(I,3),I=1,2)/4,4/
      DATA (CONFSUB(I,4),I=1,2)/6,0/
      DATA (CONFSUB(I,5),I=1,2)/10,10/
      DATA (CONFSUB(I,6),I=1,2)/12,12/
      DATA (CONFSUB(I,7),I=1,2)/13,13/
      DATA (CONFSUB(I,8),I=1,2)/15,15/
      DATA (CONFSUB(I,9),I=1,2)/17,17/
      DATA (CONFSUB(I,10),I=1,2)/18,18/
      DATA (CONFSUB(I,11),I=1,2)/0,6/

If I look at the diagrams [3], any diagram with an NP vertex doesn't seem to appear in the map. Am I missing something obvious here?

Thanks for your help!
Anna

[1] http://feynrules.irmp.ucl.ac.be/wiki/HEL
[2] http://www.crc.nd.edu/~awoodard/ttW_cuW/SubProcesses/P1_qq_ttxwp/config_subproc_map.inc
[3] http://www.crc.nd.edu/~awoodard/ttW_cuW/SubProcesses/P1_qq_ttxwp/matrix1.ps

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

Hi Anna,

The selection is not based on the presence of the NP vertex. It just present the first diagram on which we are based for the phase space mapping and event writting. The actual weight of the channel for multi-channelling weight is actually based on the sum of the amplitude of multiple diagram.

This can be seen in matrixX.f
where you have line like:

      AMP2(1)=AMP2(1)+(AMP(1)+AMP(4)+AMP(5)+AMP(6)+AMP(7)+AMP(8)
     $ +AMP(19))*DCONJG(AMP(1)+AMP(4)+AMP(5)+AMP(6)+AMP(7)+AMP(8)
     $ +AMP(19))

I do not think that this is very important in your case, but it is actually important in presence of the GIM mechanism.
Remember that the physics is not affected by the number of channel of integration (and by the value that we put in AMP2(X) -- as long as at least one is different of zero)

Cheers,

Olivier

Revision history for this message
Anna Elizabeth Woodard (annawoodard) said : 		#8

Hi Olivier,

Sorry about the delay. That makes sense. Thanks for your help!

Sincerely,
Anna