Madspin fails with majorana particle

Bug #1801760 reported by Pablo Martin
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MadGraph5_aMC@NLO
Won't Fix
Undecided
Unassigned

Bug Description

Hi,

I am running a LO event generation with decays through Madspin. I implemented my model in Feynrules, and I basically have SM + new scalar doublet with squark quantum numbers + new fermion singlet under SM.

When this fermion is a Dirac particle, everything is fine in my model. Then I want to do the same with a majorana fermion, so I change the feynrules file and try to run the same process:

define new = phiqup phiqd phiqup~ phiqd~
generate p p > new new

where phiqup and phiqd are the upper and lower components of the scalar doublet. Madspin decays:

decay t > w+ b, w+ > all all
decay t~ > w- b~, w- > all all
decay w+ > all all
decay w- > all all
decay z > all all
decay phiqup > ~psi upq
decay phiqup~ > ~psi upq~
decay phiqd > ~psi downq
decay phiqd~ > ~psi downq~

and I get the following error in Madspin in the estimation of the maximum weight:

...
...
INFO: Event 141/750 : 12.8s
INFO: Event 146/750 : 13.3s
INFO: No independent decay for one type of final states -> skip those events for the maximum weight computation
INFO: Not enough events for at least one production mode.
INFO: This is ok as long as you don't reuse the max weight for other generations.
INFO:
INFO: Decaying the events...
Command "generate_events run_01" interrupted with error:
ZeroDivisionError : float division by zero
Please report this bug on https://bugs.launchpad.net/mg5amcnlo
More information is found in '/home/pablo/programs/MG5_aMC_v2_6_3_2/bin/M9_LOPS_0+1j_all/run_01_tag_1_debug.log'.
Please attach this file to your report.
INFO: storing files of previous run
gzipping output file: unweighted_events.lhe
INFO: Done
INFO:
quit

I attach the debug file. I tried a couple of things like setting the number of events for the estimate of the max. weight to a larger number and it didn't work.

Do you have any clues about how to solve this issue? Thanks!

Cheers,

Pablo

Revision history for this message
Pablo Martin (pmartin7) wrote :
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote :

Hi Pablo,

The debug file that you send us does not seem to match with your description of the bug.

The debug file speaks about a compilation error (when generating events at NLO accuracy)
While you speak here about a error at the MadSpin level for a LO accuracy job.

Could you also send me your model/cards such that I can try to reproduce the issue and try to understand what's going on?

Cheers,

Olivier

Changed in mg5amcnlo:
status: New → Incomplete
Revision history for this message
Pablo Martin (pmartin7) wrote : Re: [Bug 1801760] Re: Madspin fails with majorana particle

Hi Olivier,

sorry I messed up with the files! I attach here all you need. Thanks very
much!

Pablo

El sáb., 10 nov. 2018 a las 20:35, Olivier Mattelaer (<
<email address hidden>>) escribió:

> ** Changed in: mg5amcnlo
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1801760
>
> Title:
> Madspin fails with majorana particle
>
> Status in MadGraph5_aMC@NLO:
> Incomplete
>
> Bug description:
> Hi,
>
> I am running a LO event generation with decays through Madspin. I
> implemented my model in Feynrules, and I basically have SM + new
> scalar doublet with squark quantum numbers + new fermion singlet under
> SM.
>
> When this fermion is a Dirac particle, everything is fine in my model.
> Then I want to do the same with a majorana fermion, so I change the
> feynrules file and try to run the same process:
>
> define new = phiqup phiqd phiqup~ phiqd~
> generate p p > new new
>
> where phiqup and phiqd are the upper and lower components of the
> scalar doublet. Madspin decays:
>
> decay t > w+ b, w+ > all all
> decay t~ > w- b~, w- > all all
> decay w+ > all all
> decay w- > all all
> decay z > all all
> decay phiqup > ~psi upq
> decay phiqup~ > ~psi upq~
> decay phiqd > ~psi downq
> decay phiqd~ > ~psi downq~
>
> and I get the following error in Madspin in the estimation of the
> maximum weight:
>
> ...
> ...
> INFO: Event 141/750 : 12.8s
> INFO: Event 146/750 : 13.3s
> INFO: No independent decay for one type of final states -> skip those
> events for the maximum weight computation
> INFO: Not enough events for at least one production mode.
> INFO: This is ok as long as you don't reuse the max weight for other
> generations.
> INFO:
> INFO: Decaying the events...
> Command "generate_events run_01" interrupted with error:
> ZeroDivisionError : float division by zero
> Please report this bug on https://bugs.launchpad.net/mg5amcnlo
> More information is found in
> '/home/pablo/programs/MG5_aMC_v2_6_3_2/bin/M9_LOPS_0+1j_all/run_01_tag_1_debug.log'.
> Please attach this file to your report.
> INFO: storing files of previous run
> gzipping output file: unweighted_events.lhe
> INFO: Done
> INFO:
> quit
>
> I attach the debug file. I tried a couple of things like setting the
> number of events for the estimate of the max. weight to a larger
> number and it didn't work.
>
> Do you have any clues about how to solve this issue? Thanks!
>
> Cheers,
>
> Pablo
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/1801760/+subscriptions
>

Changed in mg5amcnlo:
status: Incomplete → In Progress
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote :

Hi,

This was a painfull one.
The problem is linked to some optimization of the code which implicitly assumes that you have both particles and anti-particles present in your file when you have process which decays both.
In your case, you indeed ask for both particle and anti-particle to decay and you have process for both but the events that you feed in, only have one type (due to the huge difference in cross-section between the two processes).

The optimization in place then expect to re-use some of the setup from one particle to the second but since the first one does not appear, it never setup it and lead to such crash.

A simple patch is the following one:
=== modified file 'MadSpin/decay.py'
--- MadSpin/decay.py 2018-09-19 09:41:33 +0000
+++ MadSpin/decay.py 2018-11-15 15:20:52 +0000
@@ -2547,6 +2547,8 @@
                         else:
                             valid[(i, j)] = 0
                             valid[(j, i)] = 0
+ valid[(i, j)] = 0
+ valid[(j, i)] = 0

             if __debug__:
                 for i in range(len(decays)):

which prevents such optimization to occur.
I do not think that I will push such patch. Since this is a quite special scenario.

Cheers,

Olivier

PS: Did you notice the warning that some partial width are below the QCD scale and therefore that hadronization will occur before such partial decay. MG5aMC set those contribution to zero in the computation of the width.

Changed in mg5amcnlo:
status: In Progress → Won't Fix
Revision history for this message
Pablo Martin (pmartin7) wrote :
Download full text (4.6 KiB)

Hi Olivier,

the problem is solved, thanks very much for your help! Indeed sounds like a
tricky one to find out.

PS: Did you notice the warning that some partial width are below the QCD
> scale and therefore that hadronization will occur before such partial
> decay. MG5aMC set those contribution to zero in the computation of the
> width.

Yes, I did! I changed the cut in line 8094 of
madgraph/interface/madgraph_interface.py to avoid this issue (and I am
aware of what it means in terms of physics :D).

Cheers,

Pablo

El jue., 15 nov. 2018 a las 16:41, Olivier Mattelaer (<
<email address hidden>>) escribió:

> Hi,
>
> This was a painfull one.
> The problem is linked to some optimization of the code which implicitly
> assumes that you have both particles and anti-particles present in your
> file when you have process which decays both.
> In your case, you indeed ask for both particle and anti-particle to decay
> and you have process for both but the events that you feed in, only have
> one type (due to the huge difference in cross-section between the two
> processes).
>
> The optimization in place then expect to re-use some of the setup from
> one particle to the second but since the first one does not appear, it
> never setup it and lead to such crash.
>
> A simple patch is the following one:
> === modified file 'MadSpin/decay.py'
> --- MadSpin/decay.py 2018-09-19 09:41:33 +0000
> +++ MadSpin/decay.py 2018-11-15 15:20:52 +0000
> @@ -2547,6 +2547,8 @@
> else:
> valid[(i, j)] = 0
> valid[(j, i)] = 0
> + valid[(i, j)] = 0
> + valid[(j, i)] = 0
>
> if __debug__:
> for i in range(len(decays)):
>
> which prevents such optimization to occur.
> I do not think that I will push such patch. Since this is a quite special
> scenario.
>
> Cheers,
>
> Olivier
>
> PS: Did you notice the warning that some partial width are below the QCD
> scale and therefore that hadronization will occur before such partial
> decay. MG5aMC set those contribution to zero in the computation of the
> width.
>
>
> ** Changed in: mg5amcnlo
> Status: In Progress => Won't Fix
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1801760
>
> Title:
> Madspin fails with majorana particle
>
> Status in MadGraph5_aMC@NLO:
> Won't Fix
>
> Bug description:
> Hi,
>
> I am running a LO event generation with decays through Madspin. I
> implemented my model in Feynrules, and I basically have SM + new
> scalar doublet with squark quantum numbers + new fermion singlet under
> SM.
>
> When this fermion is a Dirac particle, everything is fine in my model.
> Then I want to do the same with a majorana fermion, so I change the
> feynrules file and try to run the same process:
>
> define new = phiqup phiqd phiqup~ phiqd~
> generate p p > new new
>
> where phiqup and phiqd are the upper and lower components of the
> scalar doublet. Madspin decays:
>
> decay t > w+ b, w+ > all all
> decay t~ > w- b~, w- > all all
> decay w+ > a...

Read more...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.