Hi Olivier,

We are not able to check NWA for you. I'm not even sure that we trigger a
> warning in the
> obvious case (like if the width is larger than  0.1 times the mass).
>

My bad then! I am getting a width of ~ 80 GeV for a mass of ~ 330 GeV. I
thought that was quite big but since Madspin wasn't complaining I thought
it could be ok.

Ok sound goods, so at least you can move forward with this method (which
> is more robust and likely faster than MadSpin)
>

Given such a big width, I guess it is not safe computing the cross section
with the Madspin syntax and then running the whole process using the
decay-chain syntax. Is it? I am thinking about this because the former is
about 35% larger than the latter for the benchmark I tried.

Cheers,

Pablo





El mié., 28 nov. 2018 a las 12:11, Olivier Mattelaer (<
<email address hidden>>) escribió:

> On 28 Nov 2018, at 11:26, Pablo Martin
> <<email address hidden><mailto:<email address hidden>>> wrote:
>
> Hi Olivier,
>
> thanks for your reply.
>
> This typically means that the un-weighting efficiency of the process is
> quite bad. The typical reason is that narrow-width approximation does
> not hold for that benchmark point, leading to theoretical trouble and
> issue in the Madspin method.
>
>
> I am not getting any warning about from Madspin though.
>
> We are not able to check NWA for you. I'm not even sure that we trigger a
> warning in the
> obvious case (like if the width is larger than  0.1 times the mass).
>
> But I will add this topic on my todo list (but as low priority) and will
> investigate what is happening here.
>
>
> I tried that and everything worked as expected.
>
> Ok sound goods, so at least you can move forward with this method (which
> is more robust and likely faster than MadSpin)
>
> Cheers,
>
> Olivier
>
>
>
> If you are running at LO, you have the possibility of not using MadSpin and
> to use the decay-chain syntax. (like p p > t t~, (t > w+ b, w+ > l+ vl),
> (t~ > w- b~, w-> j j ).
> You can generate your process like this to test if this goes smoothly and
> if your NWA seems to work or not (that syntax is also based on NWA, but the
> cross-section is not computed assuming NWA.
>
>
> I tried that and everything worked as expected.
>
> Cheers,
>
> Pablo
>
>
> El mié., 28 nov. 2018 a las 11:00, Olivier Mattelaer (<
> <email address hidden><mailto:<email address hidden>>>)
> escribió:
>
> Hi,
>
> The warning is actually an Information and not a warning (it is not even
> quoted as a warning actually). It just means that MadSpin is going to drop
> some events in order to keep the correct relative abondance of each
> subprocess in your sample.
> Since number are quite close in your case, the number of events dropped
> should be quite small.
>
>
> Madspin gets stuck decaying the events:
>
> This typically means that the un-weighting efficiency of the process is
> quite bad. The typical reason is that narrow-width approximation does
> not hold for that benchmark point, leading to theoretical trouble and
> issue in the Madspin method.
>
> If you are running at LO, you have the possibility of not using MadSpin
> and to use the decay-chain syntax. (like p p > t t~, (t > w+ b, w+ > l+
> vl), (t~ > w- b~, w-> j j ).
> You can generate your process like this to test if this goes smoothly and
> if your NWA seems to work or not (that syntax is also based on NWA, but the
> cross-section is not computed assuming NWA.
>
> Cheers,
>
> Olivier
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1805107
>
> Title:
>  Madspin fails to decay events for large couplings
>
> Status in MadGraph5_aMC@NLO:
>  New
>
> Bug description:
>  Hi Olivier,
>
>  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 slepton quantum numbers + new fermion singlet
>  under SM. You helped me with a tricky bug in "#1801760<tel:1801760>
> Madspin fails
>  with majorana particle" a couple of weeks ago, so you might remember
>  the model.
>
>  I found another issue. When Madspin decays the events, I am getting
>  the following warning for some of them:
>
>  INFO: All production process does not have the same total Branching
> Ratio.
>                      Therefore the total number of events after decay
> will be lower than the original file.
>                      [max_br = 0.99515608014, min_br = 0.992471423458]
>
>  which is not too bad, but if the coupling for the relevant vertex
>  (phil-psi-lepton) is too large (~3), Madspin gets stuck decaying the
>  events:
>
>  ...
>  ...
>  INFO: Event 291/300 :  2.8s
>  INFO: Event 296/300 :  2.8s
>  INFO: All production process does not have the same total Branching
> Ratio.
>                      Therefore the total number of events after decay
> will be lower than the original file.
>                      [max_br = 0.99515608014, min_br = 0.992471423458]
>  INFO:
>  INFO: Decaying the events...
>
>
>  Any clues about this one? Thanks!
>
>  Cheers,
>
>  Pablo
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/1805107/+subscriptions
>
>
> --
> You received this bug notification because you are subscribed to
> MadGraph5_aMC@NLO.
> https://bugs.launchpad.net/bugs/1805107
>
> Title:
>  Madspin fails to decay events for large couplings
>
> Status in MadGraph5_aMC@NLO:
>  New
>
> Bug description:
>  Hi Olivier,
>
>  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 slepton quantum numbers + new fermion singlet
>  under SM. You helped me with a tricky bug in "#1801760 Madspin fails
>  with majorana particle" a couple of weeks ago, so you might remember
>  the model.
>
>  I found another issue. When Madspin decays the events, I am getting
>  the following warning for some of them:
>
>  INFO: All production process does not have the same total Branching Ratio.
>                      Therefore the total number of events after decay will
> be lower than the original file.
>                      [max_br = 0.99515608014, min_br = 0.992471423458]
>
>  which is not too bad, but if the coupling for the relevant vertex
>  (phil-psi-lepton) is too large (~3), Madspin gets stuck decaying the
>  events:
>
>  ...
>  ...
>  INFO: Event 291/300 :  2.8s
>  INFO: Event 296/300 :  2.8s
>  INFO: All production process does not have the same total Branching Ratio.
>                      Therefore the total number of events after decay will
> be lower than the original file.
>                      [max_br = 0.99515608014, min_br = 0.992471423458]
>  INFO:
>  INFO: Decaying the events...
>
>
>  Any clues about this one? Thanks!
>
>  Cheers,
>
>  Pablo
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/1805107/+subscriptions
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1805107
>
> Title:
>   Madspin fails to decay events for large couplings
>
> Status in MadGraph5_aMC@NLO:
>   New
>
> Bug description:
>   Hi Olivier,
>
>   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 slepton quantum numbers + new fermion singlet
>   under SM. You helped me with a tricky bug in "#1801760 Madspin fails
>   with majorana particle" a couple of weeks ago, so you might remember
>   the model.
>
>   I found another issue. When Madspin decays the events, I am getting
>   the following warning for some of them:
>
>   INFO: All production process does not have the same total Branching
> Ratio.
>                       Therefore the total number of events after decay
> will be lower than the original file.
>                       [max_br = 0.99515608014, min_br = 0.992471423458]
>
>   which is not too bad, but if the coupling for the relevant vertex
>   (phil-psi-lepton) is too large (~3), Madspin gets stuck decaying the
>   events:
>
>   ...
>   ...
>   INFO: Event 291/300 :  2.8s
>   INFO: Event 296/300 :  2.8s
>   INFO: All production process does not have the same total Branching
> Ratio.
>                       Therefore the total number of events after decay
> will be lower than the original file.
>                       [max_br = 0.99515608014, min_br = 0.992471423458]
>   INFO:
>   INFO: Decaying the events...
>
>
>   Any clues about this one? Thanks!
>
>   Cheers,
>
>   Pablo
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/1805107/+subscriptions
>