4jet production with [LOonly=QCD] slow

Asked by Jaco ter Hoeve

Hi,

I have simulated the following channel in 4jet production in the SMEFT (triple gluon operator):

generate g g > g g g g NP=2 aS=4 QCD=4 aEW=0 QED=0 [LOonly=QCD]

and need access to the fixed order option that comes with [LOonly=QCD]. But I am experiencing a very long runtime (± 4hrs) just to compute the color-flow optimisation. It is suggested in this paper https://arxiv.org/abs/2102.00773 that one can add --jamp_optim=False to avoid upfront costs, and even set --hel_recycling=False. Indeed, this option skips the color-flow optimisation provided I run without [LOonly=QCD], in which case it only takes a couple of minutes, but it seems to have no noticeable effect when I keep [LOonly=QCD].

Is there another way that allows me to run in [LOonly=QCD] mode while speeding up the generation of the process in some way? If not, my alternative is to simply simulate events and forget the fixed order option.

Thanks a lot in advance,
Jaco

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,

Yes indeed looks like we have not thought to put a flag for that particular case.
I will try to implement the support of the flag for that particular syntax but yes in general doing LO from NLO code is expected to be super slow since the code is optimized for NLO running and not for LO running.

Just by curiosity, what is the option that are missing in the standard LO code for you to want to use this syntax?

Cheers,

Olivier

Revision history for this message
Jaco ter Hoeve (jthoeve) said :
#2

Hi Olivier,

Thanks for your answer! The reason I am using this syntax is because I would like to use the fixed order option, i.e. create HwU files, without generating events (lhe files).

Best,
Jaco

Revision history for this message
Faulkner Ehman (hydaymonolog) said :
#3

You can consider some alternative approaches to achieve your goals:

Run without [LOonly=QCD]:
As you mentioned, running without the [LOonly=QCD] option significantly reduces the computation time (only a couple of minutes). While this doesn't give you fixed-order results, it can still provide you with an approximation of the process with QCD interactions.

Run at a Lower Precision:
Madgraph allows you to control the precision of the computation. You can try lowering the precision settings to reduce the runtime. Keep in mind that this may affect the accuracy of the results, so it's essential to validate the results obtained with lower precision.

Parallelization:
If you have access to a multi-core processor or a computing cluster, you can try parallelizing the computation. Madgraph supports multi-threading, and running multiple threads can speed up the generation process.

https://www.ballsportsgames.com/double-bounce-rule-in-pickleball/

Contact Madgraph Developers or Community:
If you have exhausted the available options and are still experiencing long runtimes, consider reaching out to the Madgraph developers or the user community for suggestions and potential solutions. They might have insights or alternative approaches to deal with this specific scenario.

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

Just to follow up on this. (you can obviously ignore the chatGPT answer of a bot wanting to put an irrelevant link)

In 3.5.2, that optimization step will run much faster.
Within the SM, the g g> 5g optimization pass from close to 500s to 35s making the need of a flag close to irrelevant.
Here is the associated patch:
https://github.com/mg5amcnlo/mg5amcnlo/commit/0abbc62ac786487fa6d847c3bf6402889ffe9c8c

Can you help with this problem?

Provide an answer of your own, or ask Jaco ter Hoeve for more information if necessary.

To post a message you must log in.