WARNING: Failed to update dependent parameter

Asked by teddym on 2019-04-15

I noticed the FAQ #2885, However, I have some further question concerning this.

I have a model with LO and NLO implementation using FeynRules.

There are two situations between the restriction files and the parameter cards:

ONE: parameter a is set to zero in restriction file but we still provide it in parameter card
TWO: parameter a is provided (non-zero) in restriction file, but we didn't provide it in parameter card

When Loading LO model files, either Case ONE or Case TWO will not have any problem, as mg5 will update the parameters, to either 0 (Case ONE) or to the default value (Case TWO)

The situation is the same, when I load the NLO model, but only generate LO process.

However, when I generate NLO process (say ggF production of Higgs) with NLO model file:

In Case ONE, the program will give the warning:
WARNING: Failed to update dependent parameter
and raise the error saying that the parameter is not zero, and stop generation.
(When I use update dependent, it still return the warning: failed to update dependent parameter)

In Case TWO, it will still use the default value.

Is that just the case in the program, or my model file is not so well written? My feeling is that since in the LO process case, the program will update the parameter and set it to zero (Case ONE) or default value (Case Two), then it should also be the same for NLO process.

Thanks!

Best
Ted

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
teddym
Solved:
2019-04-15
Last query:
2019-04-15
Last reply:
2019-04-15

Hi Ted,

Actually the correct behaviour should be the NLO one,
The code should crash if you provide a non zero value for a restricted parameter.
I think it makes more sense than a warning that the user might not notice.

Now I consider that case ONE is a bug at the user side and therefore we should not stick to a given policy.
(i.e. it is fine for me if the behaviour is not the same for different model and/or type of generation).
As hinted above, I actually think that the behaviour of case ONE is actually not predictive even at LO.
(I'm pretty sure that I can reproduce the "NLO" behaviour at LO and the opposite)

Cheers,

Olivier

> On 15 Apr 2019, at 18:57, teddym <email address hidden> wrote:
>
> New question #680275 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/680275
>
> I noticed the FAQ #2885, However, I have some further question concerning this.
>
> I have a model with LO and NLO implementation using FeynRules.
>
> There are two situations between the restriction files and the parameter cards:
>
> ONE: parameter a is set to zero in restriction file but we still provide it in parameter card
> TWO: parameter a is provided (non-zero) in restriction file, but we didn't provide it in parameter card
>
> When Loading LO model files, either Case ONE or Case TWO will not have any problem, as mg5 will update the parameters, to either 0 (Case ONE) or to the default value (Case TWO)
>
> The situation is the same, when I load the NLO model, but only generate LO process.
>
> However, when I generate NLO process (say ggF production of Higgs) with NLO model file:
>
> In Case ONE, the program will give the warning:
> WARNING: Failed to update dependent parameter
> and raise the error saying that the parameter is not zero, and stop generation.
> (When I use update dependent, it still return the warning: failed to update dependent parameter)
>
> In Case TWO, it will still use the default value.
>
> Is that just the case in the program, or my model file is not so well written? My feeling is that since in the LO process case, the program will update the parameter and set it to zero (Case ONE) or default value (Case Two), then it should also be the same for NLO process.
>
>
> Thanks!
>
> Best
> Ted
>
>
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

teddym (niepanchongsheng) said : #2

Hi Olivier:
    Thanks for your answer.
    Then, I think, I should make my parameter card more consistent with the UFO model files and the restriction files.

Thanks!

Best
Ted