Error in automatic decay width calculation
Hi,
I am working on a new BSM model generated by SARAH 4.14.2. I am a new user of madgraph5. I am having some trouble in calculating decay width of a tree level process automatically using 'set Whh1 Auto'. It is showing some error messages like,
Command "generate_events run_01" interrupted in sub-command:
"set max_npoint_
NameError : name 'mdl_APP4' is not defined
Please report this bug on https:/
More information is found in 'MG5_debug'.
Please attach this file to your report.
Is it because of any problem in my model file? Can you please suggest what kind of fault may generate this kind of error messages?
Thanks in advance.
SB
Question information
- Language:
- English Edit question
- Status:
- Answered
- Assignee:
- No assignee Edit question
- Last query:
- Last reply:
Revision history for this message
|
#1 |
Hi,
This sounds like a model related problem indeed. Now it can be an error on how MG5 handle the model.
If you do
grep APP4 .-rin
inside your UFO model directory what do you get?
Cheers,
Olivier
Revision history for this message
|
#2 |
Thanks for your suggestion. After I did that. it showed,
Binary file parameters.pyo matches
Binary file model_Feynman.pkl matches
Binary file dec_model.pkl matches
param_card.dat:83: 0 22 22 0.000000e+00 # APP4
parameters.
parameters.py:4492: texname = '\\text{APP4}',
Binary file model.pkl matches
couplings.py:15615: value='
Binary file couplings.pyo matches
Thanks in advance.
SB
On Wed, Jul 8, 2020 at 5:01 PM Olivier Mattelaer <
<email address hidden>> wrote:
> Your question #691744 on MadGraph5_aMC@NLO changed:
> https:/
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> Hi,
>
> This sounds like a model related problem indeed. Now it can be an error on
> how MG5 handle the model.
> If you do
> grep APP4 .-rin
> inside your UFO model directory what do you get?
>
> Cheers,
>
> Olivier
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https:/
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https:/
>
> You received this question notification because you asked the question.
>
Revision history for this message
|
#3 |
Looks like reasonable.
Could you send me the model by email (<email address hidden>) and include a link to this page in your email?
Cheers,
Olivier
Revision history for this message
|
#4 |
Hi,
Sorry for the long delay which was due to first my holliday and then to an hackathon events who take 100% of my FLOPS available.
Note that I have those (very worrysome) warning when loading the model:
WARNING: Property color cannot be changed:Color -3 is not valid
WARNING: Property color cannot be changed:Color -3 is not valid
WARNING: Property color cannot be changed:Color -3 is not valid
WARNING: Property color cannot be changed:Color -3 is not valid
WARNING: Property color cannot be changed:Color -3 is not valid
WARNING: Property color cannot be changed:Color -3 is not valid
It likely means that some particle will not have the expected color assigned to them and therefore likely weird behavior).
The problem is actually the fact that you have two parameter with the same block and index:
APP4 = Parameter(
nature = 'external',
type = 'real',
value = 0.,
texname = '\\text{APP4}',
lhablock = 'EFFHIGGSCOUPLI
lhacode = [0,22,22] )
APP5 = Parameter(
nature = 'external',
type = 'real',
value = 0.,
texname = '\\text{APP5}',
lhablock = 'EFFHIGGSCOUPLI
lhacode = [0,22,22] )
if I change the index to [0,22,22, 1]
for one of the two then I get another error related to another parameter with the exact same issue.
Cheers,
Olivier
Revision history for this message
|
#5 |
Thanks a lot for your helpful suggestions. I checked my model and could
solve the issue regarding those unwanted vertices. But now it is showing
another kind of error while finding the decay width.
Command "generate_events run_01" interrupted in sub-command:
"set max_npoint_
KeyError : (-3, 1)
Please report this bug on https:/
More information is found in 'MG5_debug'.
Please attach this file to your report.
Is it also a model file oriented issue?
Thanks in advance.
SB
On Thu, Jul 30, 2020 at 6:15 AM Olivier Mattelaer <
<email address hidden>> wrote:
> Your question #691744 on MadGraph5_aMC@NLO changed:
> https:/
>
> Olivier Mattelaer proposed the following answer:
> Hi,
>
> Sorry for the long delay which was due to first my holliday and then to
> an hackathon events who take 100% of my FLOPS available.
>
> Note that I have those (very worrysome) warning when loading the model:
>
> WARNING: Property color cannot be changed:Color -3 is not valid
> WARNING: Property color cannot be changed:Color -3 is not valid
> WARNING: Property color cannot be changed:Color -3 is not valid
> WARNING: Property color cannot be changed:Color -3 is not valid
> WARNING: Property color cannot be changed:Color -3 is not valid
> WARNING: Property color cannot be changed:Color -3 is not valid
>
> It likely means that some particle will not have the expected color
> assigned to them and therefore likely weird behavior).
>
> The problem is actually the fact that you have two parameter with the
> same block and index:
>
> APP4 = Parameter(
> nature = 'external',
> type = 'real',
> value = 0.,
> texname = '\\text{APP4}',
> lhablock = 'EFFHIGGSCOUPLI
> lhacode = [0,22,22] )
>
> APP5 = Parameter(
> nature = 'external',
> type = 'real',
> value = 0.,
> texname = '\\text{APP5}',
> lhablock = 'EFFHIGGSCOUPLI
> lhacode = [0,22,22] )
>
> if I change the index to [0,22,22, 1]
> for one of the two then I get another error related to another parameter
> with the exact same issue.
>
> Cheers,
>
> Olivier
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https:/
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https:/
>
> You received this question notification because you asked the question.
>
Revision history for this message
|
#6 |
Without the debug file, I can not tell.
Cheers,
Olivier
Revision history for this message
|
#7 |
Here is the debug file,
#******
#* MadGraph5_aMC@NLO *
#* *
#* * * *
#* * * * * *
#* * * * * 5 * * * * *
#* * * * * *
#* * * *
#* *
#* *
#* VERSION 2.6.6 2018-06-28 *
#* *
#* The MadGraph5_aMC@NLO Development Team - Find us at *
#* https:/
#* *
#******
#* *
#* Command File for MadGraph5_aMC@NLO *
#* *
#* run as ./bin/mg5_aMC filename *
#* *
#******
set default_
set group_subprocesses Auto
set ignore_
set loop_optimized_
set loop_color_flows False
set gauge unitary
set complex_mass_scheme False
set max_npoint_
Traceback (most recent call last):
File
"/home/
line 1514, in onecmd
return self.onecmd_
File
"/home/
line 1463, in onecmd_orig
return func(arg, **opt)
File
"/home/
line 2461, in do_generate_events
switch_mode = self.ask_
File
"/home/
line 6172, in ask_run_
self.
File
"/home/
line 966, in ask_edit_cards
banner=banner)
File
"/home/
line 1038, in ask_edit_
cards=cards, mode=mode, **opt)
File
"/home/
line 1128, in ask
fct=
File
"/home/
line 1728, in timed_input
result = fct(question)
File
"/home/
line 2091, in __call__
return self.cmdloop()
File
"/home/
line 2259, in cmdloop
super(
File
"/home/
line 170, in cmdloop
stop = self.postcmd(stop, line)
File
"/home/
line 5956, in postcmd
self.
File
"/home/
line 6002, in do_update
self.
File
"/home/
line 6372, in do_compute_widths
out = self.mother_
File
"/home/
line 2288, in do_compute_widths
out = cmd.exec_cmd(line, model=opts[
File
"/home/
line 1543, in exec_cmd
stop = Cmd.onecmd_
File
"/home/
line 1463, in onecmd_orig
return func(arg, **opt)
File
"/home/
line 343, in do_compute_widths
return self.cmd.
File
"/home/
line 8165, in do_compute_widths
), skip_2body=
File
"/home/
line 331, in do_decay_diagram
return self.cmd.
File
"/home/
line 8439, in do_decay_diagram
model.
File "/home/
line 2845, in find_all_channels
part.
File "/home/
line 914, in find_channels_
self[
File "/home/
line 4424, in get_apx_decaywidth
self.
File "/home/
line 4129, in get_apx_
model, True)
File "/home/
line 4304, in get_color_
final_
File "/home/
line 1966, in color_multiplic
return color_dict[
KeyError: (-3, 1)
default_
ignore_
loop_
low_mem_
max_
automatic_
cluster_
/home/sanchari/
/home/sanchari/
(user set)
mg5amc_
/home/sanchari/
On Mon, Aug 10, 2020 at 7:50 PM Olivier Mattelaer <
<email address hidden>> wrote:
> Your question #691744 on MadGraph5_aMC@NLO changed:
> https:/
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> Without the debug file, I can not tell.
>
> Cheers,
>
> Olivier
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https:/
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https:/
>
> You received this question notification because you asked the question.
>
Revision history for this message
|
#8 |
So yes this seems to be some issue with the color handling of the model,
likely related to the error:
WARNING: Property color cannot be changed:Color -3 is not valid
WARNING: Property color cannot be changed:Color -3 is not valid
WARNING: Property color cannot be changed:Color -3 is not valid
WARNING: Property color cannot be changed:Color -3 is not valid
WARNING: Property color cannot be changed:Color -3 is not valid
WARNING: Property color cannot be changed:Color -3 is not valid
that I pointed before.
Cheers,
Olivier
Revision history for this message
|
#9 |
Yes, thanks for your helpful suggestion. I checked but problem is arising
again.
Command "generate_events run_01" interrupted in sub-command:
"set max_npoint_
OverflowError : signed integer is greater than maximum
Please report this bug on https:/
More information is found in 'MG5_debug'.
Please attach this file to your report.
Thanks in advance.
SB
Debug file:
#******
#* MadGraph5_aMC@NLO *
#* *
#* * * *
#* * * * * *
#* * * * * 5 * * * * *
#* * * * * *
#* * * *
#* *
#* *
#* VERSION 2.6.6 2018-06-28 *
#* *
#* The MadGraph5_aMC@NLO Development Team - Find us at *
#* https:/
#* *
#******
#* *
#* Command File for MadGraph5_aMC@NLO *
#* *
#* run as ./bin/mg5_aMC filename *
#* *
#******
set default_
set group_subprocesses Auto
set ignore_
set loop_optimized_
set loop_color_flows False
set gauge unitary
set complex_mass_scheme False
set max_npoint_
Traceback (most recent call last):
File
"/home/
line 1514, in onecmd
return self.onecmd_
File
"/home/
line 1463, in onecmd_orig
return func(arg, **opt)
File
"/home/
line 2461, in do_generate_events
switch_mode = self.ask_
File
"/home/
line 6172, in ask_run_
self.
File
"/home/
line 966, in ask_edit_cards
banner=banner)
File
"/home/
line 1038, in ask_edit_
cards=cards, mode=mode, **opt)
File
"/home/
line 1128, in ask
fct=
File
"/home/
line 1728, in timed_input
result = fct(question)
File
"/home/
line 2091, in __call__
return self.cmdloop()
File
"/home/
line 2259, in cmdloop
super(
File
"/home/
line 170, in cmdloop
stop = self.postcmd(stop, line)
File
"/home/
line 5956, in postcmd
self.
File
"/home/
line 6002, in do_update
self.
File
"/home/
line 6372, in do_compute_widths
out = self.mother_
File
"/home/
line 2288, in do_compute_widths
out = cmd.exec_cmd(line, model=opts[
File
"/home/
line 1543, in exec_cmd
stop = Cmd.onecmd_
File
"/home/
line 1463, in onecmd_orig
return func(arg, **opt)
File
"/home/
line 343, in do_compute_widths
return self.cmd.
File
"/home/
line 8165, in do_compute_widths
), skip_2body=
File
"/home/
line 331, in do_decay_diagram
return self.cmd.
File
"/home/
line 8455, in do_decay_diagram
part.
File "/home/
line 885, in find_channels_
if not model.keep_
File "/home/
line 100, in f_with_no_logger
out = f(self, *args, **opt)
File "/home/
line 1838, in keep_Npoint
myproc = diagram_
File
"/home/
line 1596, in __init__
self.
File
"/home/
line 1644, in get
diagram_
File
"/home/
line 1731, in generate_
sorted_legs = array.array('i', [l[0] for l in sorted_legs])
OverflowError: signed integer is greater than maximum
default_
ignore_
loop_
low_mem_
max_
automatic_
cluster_
/home/sanchari/
/home/sanchari/
(user set)
mg5amc_
/home/sanchari/
On Mon, Aug 10, 2020 at 8:20 PM Olivier Mattelaer <
<email address hidden>> wrote:
> Your question #691744 on MadGraph5_aMC@NLO changed:
> https:/
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> So yes this seems to be some issue with the color handling of the model,
> likely related to the error:
> WARNING: Property color cannot be changed:Color -3 is not valid
> WARNING: Property color cannot be changed:Color -3 is not valid
> WARNING: Property color cannot be changed:Color -3 is not valid
> WARNING: Property color cannot be changed:Color -3 is not valid
> WARNING: Property color cannot be changed:Color -3 is not valid
> WARNING: Property color cannot be changed:Color -3 is not valid
>
> that I pointed before.
>
> Cheers,
>
> Olivier
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https:/
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https:/
>
> You received this question notification because you asked the question.
>
Revision history for this message
|
#10 |
Never seen that before,
it sounds like the mathematical object that we use can not handle one value because the memory allocation is too small for the representation of an integer.
What is the highest PDG code do you have define in your model? if you have a pdg code higher than 2**32-1 then this is indeed problematic for MG5aMC.
in python you can see that the following line works:
array.array('i', [2**i-1 for i in range(32)])
but this one does not
array.array('i', [2**i for i in range(32)])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum
Cheers,
Olivier
Revision history for this message
|
#11 |
Yes. It worked. Thanks for your help. Now it's not generating those
previous kinds of errors but while calculating decay width, result is like,
Using default text editor "vi". Set another one in
./input/
set automatic_
compute_widths 25 --precision_
--path=
--output=
Please note that the automatic computation of the width is
only valid in narrow-width approximation and at tree-level.
INFO: get decay diagram for hh1
Vertexlist of this model has not been searched.
model.find_
Found 4 stable particles
INFO: current estimated error: 1.0 go to 4-body decay:
100 / 7475: 94s
200 / 7475: 291s
300 / 7475: 547s
400 / 7475: 951s
500 / 7475: 1392s
*And so on.....*
Here I have generated, Higgs -> z z. But I have checked, the same is
occurring for other two body decays also.
Thanks in Advance.
SB
On Sat, Aug 15, 2020 at 4:30 AM Olivier Mattelaer <
<email address hidden>> wrote:
> Your question #691744 on MadGraph5_aMC@NLO changed:
> https:/
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> Never seen that before,
>
> it sounds like the mathematical object that we use can not handle one
> value because the memory allocation is too small for the representation of
> an integer.
> What is the highest PDG code do you have define in your model? if you have
> a pdg code higher than 2**32-1 then this is indeed problematic for MG5aMC.
>
>
> in python you can see that the following line works:
> array.array('i', [2**i-1 for i in range(32)])
> but this one does not
> array.array('i', [2**i for i in range(32)])
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> OverflowError: signed integer is greater than maximum
>
> Cheers,
>
> Olivier
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https:/
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https:/
>
> You received this question notification because you asked the question.
>
Revision history for this message
|
#12 |
Hi,
This sounds working as expected. Looks like your model need to include four body decay to have a reasonably accurate value of the total width. Going that deep for the computation of the width is quite slow (even for the generation of the diagram to integrate).
>Here I have generated, Higgs -> z z. But I have checked, the same is
occurring for other two body decays also.
The "Auto" width does not depend of the process that you ask for (since this mode computes the total width). So obviously you can ask generate p p > t t~ or any othere process, this will not modify the computation of the total width.
Cheers,
Olivier
PS: Note that the auto-width does not include loop-induced decay (this is relevant for the Higgs if your model does not include loop-contracted vertex for ggh.
PPS: If you Higgs is 125 GeV and the Z at 90 GeV, the process Higgs > Z Z is impossible as a two body decay due to mass constraint, this occurs via a three body decay.
Revision history for this message
|
#13 |
Many thanks for your help. But this thing is still occurring for the
process p p > t t~ . I have tried several processes. It is generating
numerical values of cross sections for different processes but not decay
width. For p p > t t~ process,
Using default text editor "vi". Set another one in
./input/
set automatic_
compute_widths 1 2 3 4 --precision_
--path=
--output=
Please note that the automatic computation of the width is
only valid in narrow-width approximation and at tree-level.
INFO: get decay diagram for d
Vertexlist of this model has not been searched.
model.find_
Found 3 stable particles
WARNING: Mass gap lower than pion mass for decay of 1
decay into colored particle will be removed.
WARNING: Mass gap lower than pion mass for decay of 1
decay into colored particle will be removed.
WARNING: Mass gap lower than pion mass for decay of 1
decay into colored particle will be removed.
WARNING: Mass gap lower than pion mass for decay of 1
decay into colored particle will be removed.
INFO: get decay diagram for u
The amplitudes of 2 for final particle number 2 do not exist
INFO: get decay diagram for s
INFO: current estimated error: 1.0 go to 4-body decay:
WARNING: Mass gap lower than pion mass for decay of 3
decay into colored particle will be removed.
WARNING: Mass gap lower than pion mass for decay of 3
decay into colored particle will be removed.
WARNING: Mass gap lower than pion mass for decay of 3
decay into colored particle will be removed.
WARNING: Mass gap lower than pion mass for decay of 3
decay into colored particle will be removed.
100 / 2491: 21s
WARNING: Mass gap lower than pion mass for decay of 3
decay into colored particle will be removed.
WARNING: Mass gap lower than pion mass for decay of 3
decay into colored particle will be removed.
and so on. It has no end.
For heavy Higgs to zz, These warnings are not there, but the program is
taking infinite time as I said in the previous email. I have tried to
figure out the problem but I could not understand the warnings and the
actual problem. Any help will be greatly appreciated.
SB
On Sat, Aug 15, 2020 at 7:15 PM Olivier Mattelaer <
<email address hidden>> wrote:
> Your question #691744 on MadGraph5_aMC@NLO changed:
> https:/
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> Hi,
>
> This sounds working as expected. Looks like your model need to include
> four body decay to have a reasonably accurate value of the total width.
> Going that deep for the computation of the width is quite slow (even for
> the generation of the diagram to integrate).
>
> >Here I have generated, Higgs -> z z. But I have checked, the same is
> occurring for other two body decays also.
>
> The "Auto" width does not depend of the process that you ask for (since
> this mode computes the total width). So obviously you can ask generate p
> p > t t~ or any othere process, this will not modify the computation of
> the total width.
>
> Cheers,
>
> Olivier
>
> PS: Note that the auto-width does not include loop-induced decay (this
> is relevant for the Higgs if your model does not include loop-contracted
> vertex for ggh.
>
> PPS: If you Higgs is 125 GeV and the Z at 90 GeV, the process Higgs > Z
> Z is impossible as a two body decay due to mass constraint, this occurs
> via a three body decay.
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https:/
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https:/
>
> You received this question notification because you asked the question.
>
Revision history for this message
|
#14 |
The issue is that you are in the non-perturbative regime.
I would advise to use this trick (or do the equivalent at the model generation time)
https:/
to set all the mass of light quark (and all the width) to zero.
(and the width of the bottom if you keep it massive)
You can consider to do the same for the electron/muon but this will be less relevant.
This will avoid all those warnings about "Mass gap lower than pion mass for decay of 1".
and will forbid the code to try to compute the width of light quark which is indeed non-sense to compute.
Cheers,
Olivier
> On 21 Aug 2020, at 23:15, SB <email address hidden> wrote:
>
> Question #691744 on MadGraph5_aMC@NLO changed:
> https:/
>
> Status: Answered => Open
>
> SB is still having a problem:
> Many thanks for your help. But this thing is still occurring for the
> process p p > t t~ . I have tried several processes. It is generating
> numerical values of cross sections for different processes but not decay
> width. For p p > t t~ process,
>
> Using default text editor "vi". Set another one in
> ./input/
> set automatic_
> compute_widths 1 2 3 4 --precision_
> --path=
> --output=
> Please note that the automatic computation of the width is
> only valid in narrow-width approximation and at tree-level.
> INFO: get decay diagram for d
> Vertexlist of this model has not been searched.
> model.find_
> Found 3 stable particles
> WARNING: Mass gap lower than pion mass for decay of 1
> decay into colored particle will be removed.
> WARNING: Mass gap lower than pion mass for decay of 1
> decay into colored particle will be removed.
> WARNING: Mass gap lower than pion mass for decay of 1
> decay into colored particle will be removed.
> WARNING: Mass gap lower than pion mass for decay of 1
> decay into colored particle will be removed.
> INFO: get decay diagram for u
> The amplitudes of 2 for final particle number 2 do not exist
> INFO: get decay diagram for s
> INFO: current estimated error: 1.0 go to 4-body decay:
> WARNING: Mass gap lower than pion mass for decay of 3
> decay into colored particle will be removed.
> WARNING: Mass gap lower than pion mass for decay of 3
> decay into colored particle will be removed.
> WARNING: Mass gap lower than pion mass for decay of 3
> decay into colored particle will be removed.
> WARNING: Mass gap lower than pion mass for decay of 3
> decay into colored particle will be removed.
> 100 / 2491: 21s
> WARNING: Mass gap lower than pion mass for decay of 3
> decay into colored particle will be removed.
> WARNING: Mass gap lower than pion mass for decay of 3
> decay into colored particle will be removed.
>
>
> and so on. It has no end.
> For heavy Higgs to zz, These warnings are not there, but the program is
> taking infinite time as I said in the previous email. I have tried to
> figure out the problem but I could not understand the warnings and the
> actual problem. Any help will be greatly appreciated.
> SB
>
> On Sat, Aug 15, 2020 at 7:15 PM Olivier Mattelaer <
> <email address hidden>> wrote:
>
>> Your question #691744 on MadGraph5_aMC@NLO changed:
>> https:/
>>
>> Status: Open => Answered
>>
>> Olivier Mattelaer proposed the following answer:
>> Hi,
>>
>> This sounds working as expected. Looks like your model need to include
>> four body decay to have a reasonably accurate value of the total width.
>> Going that deep for the computation of the width is quite slow (even for
>> the generation of the diagram to integrate).
>>
>>> Here I have generated, Higgs -> z z. But I have checked, the same is
>> occurring for other two body decays also.
>>
>> The "Auto" width does not depend of the process that you ask for (since
>> this mode computes the total width). So obviously you can ask generate p
>> p > t t~ or any othere process, this will not modify the computation of
>> the total width.
>>
>> Cheers,
>>
>> Olivier
>>
>> PS: Note that the auto-width does not include loop-induced decay (this
>> is relevant for the Higgs if your model does not include loop-contracted
>> vertex for ggh.
>>
>> PPS: If you Higgs is 125 GeV and the Z at 90 GeV, the process Higgs > Z
>> Z is impossible as a two body decay due to mass constraint, this occurs
>> via a three body decay.
>>
>> --
>> If this answers your question, please go to the following page to let us
>> know that it is solved:
>>
>> https:/
>>
>> If you still need help, you can reply to this email or go to the
>> following page to enter your feedback:
>> https:/
>>
>> You received this question notification because you asked the question.
>>
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.
Can you help with this problem?
Provide an answer of your own, or ask SB for more information if necessary.