MG5 results

Hi Nady,

This is a very technical question, I'll try to be clear and simple, but if I'm not don't hesitate to tell me and I will try to explain it differently.

The integrator is nothing else than a phase-space generator, so in order to generate events, we simply have to takes the phase-space points generated by the integrator in order to compute the cross-sections. The problem is that the integrator didn't generate points according to the phase-space measure but according to another (partially adaptive) functions.
The weight keep tracks of the fact that they are not generated according to the real measure of the phase-space.

Let's give an example to be more clear. If the integrator launch twice the expected number of events in a given part of the phase-space then the weight for the events generated in this part of the phase-space will be 0.5.

The procedure of un-weighting a sample of events consists to throw away the events in order that the resulting events are distributed as in the nature.
Let's continue my above example, and suppose that the highest weight in my sample of events is 1.
Then I will keep only 50% of the events with a weight 0.5.
In practice, this choice is done event by event by launching a random number.

One additional problem is that we have split the integration in a sum of different pieces. We then define for each events a weight
which is the product of the Monte-Carlo weight (the one define above) and the probability of occurrence according to the channel of integration. This time in order to have physical distributions, we need to choose events in order that all events after the selection have the same weight (the idea, and the way to do it is exactly the same as above).

When this is understood, then the detail of the log becames quite clear (up to a technical detail)

read:
This is the number of (weighted) events read for that specific channel of integration
xsec:
This is the cross-sections associated to this specific channel of integration

Found XXX events:
This indicates the number of events after the unweighting

kept:
This is the most tricky part.
In order to optimize the unweighting, each channel performs a partial un-weighting.
All events with a weight lower than a given threshold are un-weighted up to this threshold.
This steps throw away some events. This is the reason that we print a kept.
This is the number of events passing this first unweighting.

This is an example where you can see that kept and read are not identical:

 SubProcess/Channel kept read xsec
P0_gq_llq/G1/ 1481 1481 0.224E+02
P0_gq_llq/G2/ 6248 6436 0.575E+02
P0_gq_llq/G3/ 10550 11616 0.892E+02
P0_gq_llq/G4/ 28165 29231 0.224E+03
P0_qq_llg/G1/ 28664 29730 0.228E+03
P0_qq_llg/G2/ 33202 35223 0.261E+03
P0_qq_llg/G3/ 33701 35945 0.265E+03
P0_qq_llg/G4/ 35223 37467 0.295E+03
 Found 10303 events writing first 10000

If you want additional information on the principle of the weithing/unweighting.
You can look at the talk of Johan (for a school on MadGraph) (They are some nice plot which will help you to understand this):
https://server06.fynu.ucl.ac.be/projects/madgraph/attachment/wiki/SchoolKias/MadGraph/KIAS-MG5-lectures1-2.pdf
(slides 65 to 81)