High number of channels and computation time

Hi,

I actually have 2316 diagrams for that process (assuming b to be massless). Are you sure of your numbering of diagram?

Otherwise, speed of our computation is of course something that we always try to improve.
For your process our latest paper on speed update is the following one:
    2102.00773 [hep-ph]

Which given the number of helicity for your process (36)
and the number of amplitude that cancel for some helicity(46320 out of 83376=(36*2316))
should give you a factor close to 1.5 from the advance filtering and likely a factor 4 for the advance helicity recycling.
So likely a factor 6 times faster than before.

In that paper we also introduce
- a more efficient phase-space integrator for that kind of topology (you can check if it is the case for your case or not)
- possibility to control very advance speed related parameter via the run_card.dat (via a block of parameter hidden by default but you can use the "update" command within the interactive user interface to make it happen (the exact command to use should be written in the run_card).

I'm testing right now within 2.9.13 and speed for that process is actually quite amazing given the complexity of the process.
Also the number of channel actually used is only 400.

Cheers,

Olivier

PS: The current beta version of the code of the feature version (3.5.0) should also contains an small speed bump for this process since it speed-up by a factor two (actually a bit smaller than two) the time to compute the color-matrix of the computation.
Obviously, I do not expect this process to be dominated by the color-matrix, so the speed-bump is likely only between 5 and 15%

PPS: We are actually working on another times 4 speed improvement for this process but this is not yet ready for production (still in early alpha stage).

Hello,

I'm sorry. The process that I meant was e+ e- > e+ e- b b~ b b~ /h QED==6 QCD==0 ( and here we have 2304) using the model: sm-full, with this invariant mass cuts:
{'5': 100.0 } = mxx_min_pdg
{'5': True} = mxx_only_part_antipart

( and in my case I use 280 GeV for Ecm)

But in the process that I refer before, what did you make the process faster? More precisely, what were your commands?

Can you explain this please
>>> "Which given the number of helicity for your process (36)
and the number of amplitude that cancel for some helicity(46320 out of 83376=(36*2316))
should give you a factor close to 1.5 from the advance filtering and likely a factor 4 for the advance helicity recycling."

I try not to update because I've had problems later with other programs.

Thanks,

Francisco

Hi,

The first question is why are you using sm-full?
That model include the mass of the muon and b quark.
This means that the matrix-element is much more complicated and that the number of contributing helicity will increase significantly as well.
So if you do not have a physics consideration that explains why you need to keep such mass term, I would suggest dropping them since they are in general negligible (but off course you need to check at least once).

For my test , I just did

import model sm-no_b_mass
generate e+ e- > e+ e- b b~ b b~ QED==6 QCD==0
output
launch

> I try not to update because I've had problems later with other programs.

It is your right to not use the latest version of the code. But then do not complain that the code is too slow.

>Can you explain this please ...

The best is to read 2102.00773 [hep-ph] where this is explained in detail.

Note that for the x2 speed provided by 3.5.0, it is related to the following paper: 2210.07267 [hep-ph]

Cheers,

Olivier

Hi,

Sincerely, I already used one time the sm-full model and from that point I always use that model.
( I used the sm-full to simulate all higgs decay) You can recommend articles about the MadGraph model and its implications in the cross-section/matrix-element.

> It is your right to not use the latest version of the code. But then do not complain that the code is too slow.
About this, when we update MadGraph, ca problems arise in your interaction with other programs (Pythia8, ROOT and Delphes)?

Thanks,

Francisco.

P.S: You know some online workshop or something like that about MadGraph and the programs used in it?
thanks for the help about MadGraph

Hi,

> Sincerely, I already used one time the sm-full model and from that point I always use that model.
> ( I used the sm-full to simulate all higgs decay) You can recommend articles about the MadGraph model and its implications in the cross-section/matrix-element.

I'm not aware of such paper.
They are obviously a lot of paper discussing the physics difference between 4 and 5 flavor computation.
(sm-full is doing four flavour computation).

As long as speed is not an issue or relevant, you can certainly always use sm-full or the equivalent within 5 flavor computation. But if speed starts to be an issue, then you should ask yourself
if you REALLY need to simulate a non-diagonal CKM matrix and if you REALLY need to simulate effects that are proportional to the mass of the lepton /...
For those they are no universal answer.

Cheers,

Olivier

> On 17 Feb 2023, at 15:55, Francisco Casalinho <email address hidden> wrote:
>
> Question #705043 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/705043
>
> Francisco Casalinho posted a new comment:
> Hi,
>
> Sincerely, I already used one time the sm-full model and from that point I always use that model.
> ( I used the sm-full to simulate all higgs decay) You can recommend articles about the MadGraph model and its implications in the cross-section/matrix-element.
>
>> It is your right to not use the latest version of the code. But then do not complain that the code is too slow.
> About this, when we update MadGraph, ca problems arise in your interaction with other programs (Pythia8, ROOT and Delphes)?
>
> Thanks,
>
> Francisco.
>
> P.S: You know some online workshop or something like that about MadGraph and the programs used in it?
> thanks for the help about MadGraph
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.