MadGraph5_aMC@NLO

HTML file

Asked by Fatima

Dear experts
I have two questions and would appreciate your help.
(1) Number of Events in HTML Result:
In my run_card, I set 10000 events. However, in the HTML results file, I found:
• Unweighted events: 24379.0
• Events (K): 1829.85
I am not sure which of these numbers should be considered when calculating luminosity or when reporting the results. Could you please clarify which value is physically relevant?
(2) Rapidity Range and Cross Section:
In the run_card.dat, I set the pseudorapidity limits for charged leptons as follows:
Case 1:-2.0 = etal ! max rap for the charged leptons
 -1.0 = etalmin ! main rap for the charged leptons
Cross section: 5.941×10⁻⁶ pb, Unweighted events: 24379.0
Case 2:
-1.0 = etal ! max rap for the charged leptons
 0.0 = etalmin ! main rap for the charged leptons
Cross section: 5.927×10⁻⁶ pb, Unweighted events: 20051.0.
Although the cross sections are approximately the same, the number of unweighted events changes noticeably. Could you please explain why this happens?
In the file kin_functions.f, the rapidity is defined as:
rap = .5d0*dlog((pm+p(3))/(pm-p(3)))+cm_rap
But in the run_card.dat, the absolute value of the pseudorapidity (|η|) seems to be considered. Could you please clarify what exactly happens when we change the rapidity limits in the run card?
Also, in experimental analyses such as those from CMS, I noticed that they typically use a cut like |η| < 2.4 for charged leptons. How should I interpret this limit in comparison to what MadGraph uses?
Thank you very much for your time and help.
Best regards,
Fatemeh Najafi

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Olivier Mattelaer
Solved:
Last query:
Last reply:
Revision history for this message
Sihyun Jeon (shjeon) said : 		#1

1.
I do not think you should be looking at those and instead get info from

crossx.html
or
Events/<tagname>/<tagname>_tag_1_banner.txt

in your output directory and look at how many events are produced and how large the cross section is.

Those are (IIUC) number of events generated per subprocess and number of events surviving during unweighting.

Revision history for this message
Sihyun Jeon (shjeon) said : 		#2

2.
I am more or less guessing (Olivier will be able to correct me if I am wrong), if you set the min eta to be 0, although numerically it's impossible to get a lepton hitting exactly at 0.0000... , the cut you give is going to affect the phase space integration hence the changes are there in cross sections. regarding the unweighted events you see from that HTML, it's because the phase space integration changed, unweighting becomes less/more efficient. (But again, those "Events (K)" are not what you should be using as I wrote in 1.)

Revision history for this message
Sihyun Jeon (shjeon) said (last edit ): 		#3

3.
Regarding the eta cut you've mentioned about experiments, it depends on what you want to do. If you want to get rough ball park estimates, giving the same eta cut might be fine. If you want to do things more precisely, you need to shower them (since this will shake around lepton pt/eta) and then do the full analysis

Revision history for this message
Fatima (physiquefa) said : 		#4

Thank you very much for your response.
In the file Events/<tagname>/<tagname>_tag_1_banner.txt, the following information is provided:
# Number of Events : 10000
# Integrated weight (pb) : 5.940820000000093e-06.
But the table in results.html used the number of Unwgt event to find the luminosity.

Revision history for this message
Sihyun Jeon (shjeon) said : 		#5

what is your definition of "luminosity"?

Revision history for this message
Fatima (physiquefa) said : 		#6

Number of event= cross secion. luminosity

Revision history for this message
Sihyun Jeon (shjeon) said (last edit ): 		#7

then, 10000/5.940820000000093e-06 , or am i missing something?

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

The luminosity column present in the html page is an information which is designed for debugging and not for physics.
That information is the luminosity which correspond to the number of events generated for a given channel.
so in that case L = N/cross.
In that case N is the number of unweighted events.

Now for our final sample, we do need to combine those sample, and the sample that will limit the size of our COMBINED sample, will be the one with the smallest of such luminosity (and therefore the one to focus when we have issue with the phase-space integration).

Our final sample will therefore have a luminosity which is close to that minimal value (typically even lower than that) because all sample with higher luminosity than the minimal means that we need to include less event than the number generated in the combination sample.

Also remember that quite often the cross-section per channel of integration are NOT gauge invariant and on their own not physically relevant.

The column (Events (K):) is also for debugging only, since this is the total number of evaluation of the matrix-element (for the sum of the iteration).

Concerning your question on the eta. If you quote the "sum of the unweighed events" per channel.
This is also a quite unphysical technical number. (i.e. never use that one for physics).
The system in itself is chaotic so any small change (seed included) can have large impact on such metric.
So if you want to compare the efficiency of the phase-space integrator for different cut/... then one need to run multiple times to be able with different seed to be able to compare the range of both scenario.

Cheers,

Olivier

Revision history for this message
Fatima (physiquefa) said : 		#9

Thanks Olivier Mattelaer, that solved my question.