Issuing a warning (perturbativity of internal couplings)

This would be quite hacky at best and not sure that it will work in all cases.

The only method that you can technically use is the check of the model restriction (that the user can bypass and which is sometimes bypassed automatically (like if too slow)) but they are no clean way to instruct MG5 to implement a check that it was not designed for (especially without impacting the fortran version of the model).

Maybe the best is to design a new UFO file with tests that have to be run and what :to do" if such check fail. (like should we print a dedicated warning and/or crash/return 0? But then obviously this will only work for future version of the code.

Cheers,

Olivier

Dear Olivier - thanks for the answer.

Indeed as you say the cleanest way would be to have a proper check performed after recalculation of the parameters, with the definition to be specified by the UFO files.

We were thinking something like this would do:

in parameters.py have a proper line, e.g.

lam = Parameter(name = 'lam',
                nature = 'internal',
                type = 'real',
                value = 'MH**2/(2.*vev**2)',
                texname = '\\text{lam}',
                allowedranges = [(0,12.56)] )

and then in MG5, in model_reader.py, a simple check would do the job:

           if not any(lower <= param.value <= upper for lower, upper in param.allowedranges) :
               logger.warning("{param.name} = {param.value} is outside all specified ranges {param.allowedranges}.")

(this would go below param.value = complex(eval(param.name)),
plus some sanity check, and clearly attribute propagation additions..)

Then if one wants Feynrules to produce the above UFO, some changes will be needed also there. With Miha we have discussed a bit with B. Fuks, and will discuss more in a while.

What do you think?

Thanks !
Fabrizio

I was more thinking to have a new file with lines of the type:

Higgsperturbativity = ModelValidity(name='Higgsperturbativity',
                            severity='crash',
                            message='Higgs coupling out of perturbativity bound',
                            parameters = {'minvalue': 0, 'maxvalue': 12.56},
                            conditions=['minvalue <= lam',
                                                    'lam <= maxvalue']
)

This should allow much more flexibility and having a new dedicated file, should also create less issue for code that does not handle such option.

Cheers,

Olivier

Even nicer, and completely customizable

It is bit longer to code on both sides, i.e. one needs to read the file and have a new function in MG to set up checks... maybe not so difficult?

thanks! let's think

Well likely a bit longer to code but not that much now it depends on how I do implement it.
If i keep the check at the python level then they are no real issue.
If I want to move the check at Fortran/C level then I would need to parse more complex expression.

Cheers,

Olivier

> On 27 Nov 2023, at 11:30, Fabrizio Nesti <email address hidden> wrote:
>
> Question #708411 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/708411
>
> Fabrizio Nesti posted a new comment:
> Even nicer, and completely customizable
>
> It is bit longer to code on both sides, i.e. one needs to read the file
> and have a new function in MG to set up checks... maybe not so
> difficult?
>
> thanks! let's think
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

But I understand the model parameters are recalculated in python, so it should be enough to check there, right?

(Actually there is a write_param_card.py inside the UFO that one could use to completely delegate checks to the UFO code, but that is old?)

> But I understand the model parameters are recalculated in python, so it
> should be enough to check there, right?

Well the python level check are not always run. So I would not trust them.

> (Actually there is a write_param_card.py inside the UFO that one could
> use to completely delegate checks to the UFO code, but that is old?)

MG5aMC does not use that file.
Technically, we convert the UFO model to "our" internal python representation.
(like all parameter are prefixed by mdl_, some vertex are optimised, removed, renamed, ...) and therefore in practise we
are not using the UFO routine internally which is in particular True for the way the card is written.
(and actually here the problem is more when you read the card and not when you write it)

Cheers,

Olivier

> On 27 Nov 2023, at 11:55, Fabrizio Nesti <email address hidden> wrote:
>
> Question #708411 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/708411
>
> Fabrizio Nesti posted a new comment:
> But I understand the model parameters are recalculated in python, so it
> should be enough to check there, right?
>
> (Actually there is a write_param_card.py inside the UFO that one could
> use to completely delegate checks to the UFO code, but that is old?)
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.