MadGraph5_aMC@NLO

Prevent grid refinement when generating from gridpack

Asked by Philipp Windischhofer

Hi Olivier,

In ATLAS we are looking into generating a large-scale event sample for a loop-induced process (i.e. using the LO code). For reasons of computational efficiency, it is very important for us that the event generation is as fast as possible, and that as many steps as possible are amortized into the gridpack.

When generating the gridpack "out of the box", we noticed that each event generation run spends a significant amount of time "refining" the integration grid before the actual generation commences. This can sometimes take many hours, and since we're planning to launch many thousands of such generation jobs, would result in significant duplication of calculations.

We are therefore looking into ways to increase the accuracy of the gridpack so that the refinement stage is shortened, or eliminated entirely.

I found the discussion here (https://github.com/mg5amcnlo/mg5amcnlo/issues/12) which seems to hint that increasing the "iterations" and "points" arguments passed to survey could achieve what we want. Trying various different combinations, it is not clear to us that this has the desired effect. In some instances, the gridpack creation failed due to numerical inaccuracies, while in others, the gridpack generation succeeds but the grid refinement during event generation is not significantly shortened.

Could you please confirm if these are indeed the correct parameters to target? We're modifying these lines: https://github.com/mg5amcnlo/mg5amcnlo/blob/main/madgraph/interface/madevent_interface.py#L2578-L2581

Looking at the relevant parts of the code (https://github.com/mg5amcnlo/mg5amcnlo/blob/main/madgraph/interface/madevent_interface.py#L2576-L2616) it seems that the "refine" comment is indeed only run during the event generation, but not the gridpack building. Does it make any sense to try to also run "refine" at the end of the gridpack calculation? (I.e. would its results be included in the gridpack and could therefore help to shorten the refinement during the event generation?)

Thanks for your guidance!

Best,
Philipp

Question information

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

Hi,

The refine is the step that does the (weighted) events generation.
So I'm not sure about your assesment of the situation here.

If the code is too slow, you have to check two points:
1) What is the unweighting efficiency (i.e. how many weighted events do you need to generate one un-weighted event)
2) What is the time to evaluated the matrix-element (and therefore the fraction of loop that need to be evaluated in quadruple precision)

For the second, they are not that much that we can do if the double precision is too slow. If you often go to quadruple precision then you can play with the various loop tools available (in particular ninja and collier are typically helping), having stronger cut can also help here.

For the first, you can play with the parameter of the phase-space integrator to try to find a better phase-space parametrization.
Adding iteration will likely not really help at this stage since either you have reach the optimal grid, either the grid is not able to find a decent solution.

In https://arxiv.org/pdf/1507.00020.pdf, we introduced this parameter:
max_npoint_for_channel
as indicated in the paper, keeping the value to 3 (the default before we introduced that parameter) is in general the best strategy but we found processes where setting it to 4 was helpful.

Cheers,

Olivier

Can you help with this problem?

Provide an answer of your own, or ask Philipp Windischhofer for more information if necessary.

To post a message you must log in.