FO mode, summing weights before calling user routine
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MadGraph5_aMC@NLO |
Fix Released
|
Undecided
|
Rikkert Frederix |
Bug Description
Dear experts,
I am using MG5_aMC_v2_6_0, process p p > t t~ j [QCD] in fixed-order mode NLO. I've noticed that despite the attempt to sum the weights for each contribution (LO, virtual or real), sometimes the user routine is called twice for the virtual contribution. Looking into the code in subroutine fill_plots() I've realised that the two external particle momenta can be swapped, then such weights do not get combined. I give a printout of one of such events in the end.
It is nothing wrong if just filling histograms with the supplied weights, possibly only a performance issue. However, when using aMCfast interface to fill ApplGrid tables (running with iappl = 1 or 2), such multiple calls lead to wrong filling of tables, because the full virtual contribution gets written to the table twice (it is determined in the fill_applgrid_
Please let me know what do you think? Would it be possible to resolve this feature by e.g. sorting the list of particles in pT or E, at least to improve performance?
Best regards,
Sasha.
_______
Below is one event to demonstrate the case.
Printout is done in the fill_plots routine, and later in the user routine.
Lines starting with " i = " represent weights, for each such weight its type (plot_id), actual weight and particle momenta are printed; after this a message can appear that weight i = .. is added to ii = ...
You can see that weight for i = 4 is not added to ii = 2 group of virtual weights because of momenta [5] and [6] swapped, as a result there are two calls of the user routine with " ibody = 2".
i = 1 plot_id(i) = 20 wgt = 1.2675138942124
momenta:
[1]
219.6 0.0 0.0 219.6
[2]
219.6 0.0 0.0 -219.6
[3]
185.0 -50.1 21.4 -38.5
[4]
198.6 53.3 -76.6 31.7
[5]
55.6 -3.2 55.1 6.8
[6]
0.0 -0.0 -0.0 -0.0
adding i = 1 to ii = 1
i = 2 plot_id(i) = 12 wgt = 3.6921639153892
momenta:
[1]
219.6 0.0 0.0 219.6
[2]
219.6 0.0 0.0 -219.6
[3]
185.0 -50.1 21.4 -38.5
[4]
198.6 53.3 -76.6 31.7
[5]
55.6 -3.2 55.1 6.8
[6]
0.0 -0.0 -0.0 -0.0
adding i = 2 to ii = 2
i = 3 plot_id(i) = 12 wgt = 4.5032687998826
momenta:
[1]
219.6 0.0 0.0 219.6
[2]
219.6 0.0 0.0 -219.6
[3]
185.0 -50.1 21.4 -38.5
[4]
198.6 53.3 -76.6 31.7
[5]
55.6 -3.2 55.1 6.8
[6]
0.0 -0.0 -0.0 -0.0
adding i = 3 to ii = 2
i = 4 plot_id(i) = 12 wgt = -4.188708471761
momenta:
[1]
219.6 0.0 0.0 219.6
[2]
219.6 0.0 0.0 -219.6
[3]
185.0 -50.1 21.4 -38.5
[4]
198.6 53.3 -76.6 31.7
[5]
0.0 -0.0 -0.0 -0.0
[6]
55.6 -3.2 55.1 6.8
adding i = 4 to ii = 4
i = 5 plot_id(i) = 11 wgt = 2.0189885456377
momenta:
[1]
306.2 0.0 0.0 306.2
[2]
370.0 0.0 0.0 -370.0
[3]
190.3 9.5 70.0 -38.5
[4]
213.1 118.7 -23.3 31.7
[5]
198.4 -145.7 -118.7 -63.7
[6]
74.4 17.5 72.0 6.8
adding i = 5 to ii = 5
<<<<<<
ibody = 3 www = 1.2675138942124
ibody = 2 www = 4.5401904390365
ibody = 2 www = -4.188708471761
ibody = 1 www = 2.0189885456377
<<<<<<
Changed in mg5amcnlo: | |
assignee: | nobody → Rikkert Frederix (frederix) |
Changed in mg5amcnlo: | |
status: | New → Fix Committed |
Changed in mg5amcnlo: | |
status: | Fix Committed → Fix Released |
Dear Sasha,
Sorry for the delay.
I think you are right that there is indeed a problem with the filling of the ApplGrid tables. If I understand correctly, when determining the weights for ApplGrid, all different non-Born n-body contributions (i.e., the counter-terms, the virtual and/or the approximated virtual) are summed together. However, when going into the plotting routines, since they can have different momenta (even though they would be identical for various IR-safe observables) in rare cases, the plotting routines could be called twice. But since the ApplGrid weights are already summed (contrary to the weights that are used to make the fixed-order NLO plots), in the case where one calls the plotting routines twice, the weights for these non-Born n-body configurations are --incorrectly-- added twice to the ApplGrid tables.
Thanks for pointing this out. I'll try to find a solution.
Best,
Rikkert