DECAY block in param card and info on interaction orders

Asked by Ilaria Brivio

Dear authors,

I have two independent questions:

1. I was wondering in what cases the DECAY block is compulsory for a param_card to be considered valid.
I have a model where this is absent, because decay widths are all defined as internal parameters.
generating events does not give any issue, but I noticed that the reweighting works only if the parameters values are changed with "set frblock 1 1 " etc. while if I pass the path of a param_card as an argument, it is not accepted and the reweighting returns zero cross section.
I have checked that indeed inserting a dummy DECAY block in the imported param_card fixes the issue, but I'd like to know if there are other cases where this can be problematic.

2. is there any reference where I can find an exhaustive description of all the allowed (and not allowed) interaction order specifications and their interplay with the syntax for the definitions of processes? I figured some of this empirically (eg NP==1 does is not accepted together with a comma that splits a process in production+decay) but I couldn't find anything 'official' about it.

Thank you very much!
Ilaria

Question information

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

> 1. I was wondering in what cases the DECAY block is compulsory for a param_card to be considered valid.

To be considered as valid: ALWAYS. The decay block should be present for ALL particles.
(like the mass of all particles)

> I'd like to know if there are other cases where this can be problematic.

Actually they are plenty of cases where this can pop-up (basically any post event generation tools including MadSpin, Pythia, reweighting, mass reshufling, ...

> 2. is there any reference where I can find an exhaustive description of all the allowed (and not allowed) interaction order specifications and their interplay with the syntax for the definitions of processes? I figured some of this empirically (eg NP==1 does is not accepted together with a comma that splits a process in production+decay) but I couldn't find anything 'official' about it.

No we do not have that in a document.
using "help generate" command is the best way to have the information (the manual IS the code as usual). But is not very explicit on that point.

Cheers,

Olivier

> On 13 May 2020, at 11:45, Ilaria Brivio <email address hidden> wrote:
>
> New question #690677 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/690677
>
> Dear authors,
>
> I have two independent questions:
>
> 1. I was wondering in what cases the DECAY block is compulsory for a param_card to be considered valid.
> I have a model where this is absent, because decay widths are all defined as internal parameters.
> generating events does not give any issue, but I noticed that the reweighting works only if the parameters values are changed with "set frblock 1 1 " etc. while if I pass the path of a param_card as an argument, it is not accepted and the reweighting returns zero cross section.
> I have checked that indeed inserting a dummy DECAY block in the imported param_card fixes the issue, but I'd like to know if there are other cases where this can be problematic.
>
> 2. is there any reference where I can find an exhaustive description of all the allowed (and not allowed) interaction order specifications and their interplay with the syntax for the definitions of processes? I figured some of this empirically (eg NP==1 does is not accepted together with a comma that splits a process in production+decay) but I couldn't find anything 'official' about it.
>
> Thank you very much!
> Ilaria
>
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Ilaria Brivio (ilariab) said :
#2

Hi Olivier,

thanks a lot. Every thing is much clearer now.

cheers,
Ilaria