Issue with Auto width and add process

Hi,

Without knowing your model, it is difficult to comment because this can be the correct answer.
One reason can be that the following process does exists:
S > z ve vm
in that case assuming that all of the 9 combination
S > z vnew vnew
have the same strength then it is easy to explain your factor of three.

But this is only a guess. The fact that the first syntax is bigger than the second might be a bug obviously (in that case I would need the model) or just that the first syntax does include additional channel.

> When I set the decay width to "Auto" then it only considers the two-body decay and not the three-body decay.

Did you read the paper (1402.1178)? "Auto" is just a shortcut to a dedicated function (compute_widths) which has many parameter that you can tune. In particular, it does only include three body decay if they are estimated to be bigger than a given threshold of the full cross-section. In the paper, it is written how to remove the threshold and always include the three body decay.

Cheers,

Olivier

Hi Olivier,

Thank you very much.

I checked it before I do not have those combinations like "ve vm". I will share the UFO model file with you. I will also share the reference point.

Yes, the paper 1402.1178 is mentioned in many places on Launchpad so I saw it and used those options like "--body decay=3" but still only 2 body decay was there.

Best regards,
Sarif Khan

So the issue is related to the strategy of grouping
set group_subprocesses True returns one value while set group_subprocesses False
returns the second value.

Looks like the default value "Auto" is for one of your syntax using "True" and for the second syntax using "False".
Actually, the difference occur even for a single decay channel.
At this stage, I would not trust more one mode compare to the other.

Cheers,

Olivier

Hi,

Using git bisect the responsible commit for this issue is:

https://github.com/mg5amcnlo/mg5amcnlo/commit/83b3c6c1a8953681031524aa1ca55d456158070a is the first bad commit
commit 83b3c6c1a8953681031524aa1ca55d456158070a
Author: olivier-mattelaer <>
Date: Sat Sep 26 09:28:37 2020 +0200

    put a max to multi-channel

 madgraph/iolibs/export_v4.py | 11 +++++++----
 madgraph/madevent/hel_recycle.py | 1 +
 2 files changed, 8 insertions(+), 4 deletions(-)

Not sure if this is not a false flag but will check this carefully

Sorry to have been slow on this, I'm restarting to look at this only now.

I have made a bit of progress, the actual problem is the following version:
https://bazaar.launchpad.net/~maddevelopers/mg5amcnlo/2.7.3_tflipping/revision/318
and looks like this is within the genps.f file that the bug was introduced.
I hope that I will be able to fix this tommorow and release 2.9.17 right after that.

Sorry,

Olivier