Comment 5 for bug 1801760

Revision history for this message
Pablo Martin (pmartin7) wrote : Re: [Bug 1801760] Re: Madspin fails with majorana particle

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+ > 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
>