MG5 generates 10k events, Pythia only uses ~1% of them

Hi,

I guess that this is rather a question to the pythia author. I have never seen this error before so I will not be able to help you on this subject.

Cheers,

Olivier

On Oct 30, 2014, at 1:36 PM, TMartin <email address hidden> wrote:

> New question #256417 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/256417
>
> Hi, my collaborators and I have created our own model using FeynRules, and it works great for most of the parameter space.
>
> For a subset of the parameter space where the mass spectra of the new particles is compressed (~20 GeV), we get a lot of errors when running Pythia on the MadGraph output. We aren't sure why or who to ask about this. Of note, I just downloaded the latest version of MG5 (as of this morning), and reinstalled the latest versions of pythia-pgs, Delphes3, ExRootAnalysis, etc using the MG5 interface "install" command.
>
> I just ran a test on this to see if I could figure out where the problem lies. I generated 10k events of p p > particle1 particle2 in MadGraph, and then included IMSS(22)=24 in the pythia_card.dat in order to have Pythia decay these states isotropically according to the param_card decay table (which has 3 body decays for the compressed spectra).
>
> The unweighted_events.lhe file from MG5 does include 10000 events. I confirmed this.
>
> The pythia_events.lhe file includes only 141 events. I confirmed this.
>
> The pythia.log file also states only 141 events generated. Here is the relevant part of the pythia.log file:
>
> Failed to read LHEF event information,
> assume end of file has been reached.
> 1********* PYSTAT: Statistics on Number of Events and Cross-sections *********
>
> ==============================================================================
> I I I I
> I Subprocess I Number of points I Sigma I
> I I I I
> I----------------------------------I----------------------------I (mb) I
> I I I I
> I N:o Type I Generated Tried I I
> I I I I
> ==============================================================================
> I I I I
> I 0 All included subprocesses I 141 10000 I 2.614D-11 I
> I 4 User process 0 I 141 10000 I 2.614D-11 I
> I I I I
> ==============================================================================
>
> ********* Total number of errors, excluding junctions = 10895 *************
> ********* Total number of errors, including junctions = 10896 *************
> ********* Total number of warnings = 0 *************
> ********* Fraction of events that fail fragmentation cuts = 0.98590 *********
>
>
> Notes:
> We are not running matching/merging on these events.
> We have run the same process on many different computers, with available RAM ranging from 4GB to 8GB, and it always occurs.
> We have run this with 10k events and 50k events, and it is still ~1% of events that pass through Pythia.
> None of the events that pass through Pythia are sequential (ie: in the case of the log file above, the 141 events are scattered throughout the 10000 events generated by MG5, rather than the first 141 events). This statement is based solely on comparing the first few events of pythia/MG5 and noting that the interacting partons are different for the event entries.
>
> Any help would be greatly appreciated. Thank you.
>
>
> Of note, the upper part of the pythia.log file also includes these lines:
>
> Starting event loop
>
> Error type 3 has occured after 0 PYEXEC calls:
> (PYRESD:) daughter masses too large
>
> Error type 3 has occured after 0 PYEXEC calls:
> (PYRESD:) daughter masses too large
>
> Error type 3 has occured after 0 PYEXEC calls:
> (PYRESD:) daughter masses too large
>
> Error type 3 has occured after 0 PYEXEC calls:
> (PYRESD:) daughter masses too large
>
> Error type 3 has occured after 0 PYEXEC calls:
> (PYRESD:) daughter masses too large
>
> Error type 3 has occured after 0 PYEXEC calls:
> (PYRESD:) daughter masses too large
>
> Error type 3 has occured after 0 PYEXEC calls:
> (PYRESD:) daughter masses too large
>
> Error type 3 has occured after 0 PYEXEC calls:
> (PYRESD:) daughter masses too large
>
> Error type 3 has occured after 0 PYEXEC calls:
> (PYRESD:) daughter masses too large
>
> Error type 9 has occured after 0 PYEXEC calls:
> (PYEVNW:) failed to evolve shower or multiple interactions. Returning.
>
>
> I am not sure why this would be occurring, as I used MG5 to calculate the decay widths/branching ratios for the param card, and have verified that the sum of the masses of the daughter particles are less than the mass of the decaying state for ALL decay modes. Since the produced particles are being generated on-shell, I am not sure why this would happen. Setting the BWCUTOFF to 400 also does not resolve this (not sure why it would, but I thought I would check).
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Olivier,

I appreciate your quick response, and I understand that this may not be a MG5 issue.

I have since tracked down where I think the problem is, and it may indeed by a Pythia issue in the end, but I want to explain it to you since I have just found out that Pythia 6 is not supported by the Pythia people any longer, and Pythia 6 is the version that comes with MG5. If you still don't feel that this can/should be resolved in MG5, and that this is a Pythia issue, then I will leave you alone.

The problem has to do with the decay table. MG5 calculates the decays automatically, but it does it at the parton level. So, for example, an s u~ LSP (or even d u~) decay is possible based on the masses of the light quarks in the param card. But when this is passed to Pythia, I think Pythia tries to hadronize the s and the u~ separately. So it treats them as two mesons which have a combined mass larger than the invariant mass that is available.

So what I think the problem is is that MG5 treats decays in terms of (very) light quarks, but Pythia hadronizes those immediately and thus spits out an error due to the masses of the daughters being heavier than the mass of the parent. This is why the issue only occurs for the compressed spectra scenarios I am experiencing.

Hi,

> The problem has to do with the decay table. MG5 calculates the decays
> automatically, but it does it at the parton level. So, for example, an s
> u~ LSP (or even d u~) decay is possible based on the masses of the light
> quarks in the param card. But when this is passed to Pythia, I think
> Pythia tries to hadronize the s and the u~ separately. So it treats them
> as two mesons which have a combined mass larger than the invariant mass
> that is available.

What is the available energy for the pair s u~? if the difference of mass between your LSP and your super-partner is smaller
than the mass of the pion, then clearly you are facing a forbidden channel of disintegration.

A second potential problem can happen if the partial width (and/or total width) of the super-particle is smaller than \Lambda_QCD it also means that the perturbative theory use by MadWidth is not valid anymore.
In that case, the super particle is going to hadronize first and therefore I have no idea (don’t think that anyone knows in such case) how to make the computation…

So I would say that you are using MadWdith outside it’s range of validity. I’m going to print some warning for this kind of scenario.

Cheers,

Olivier

On Oct 30, 2014, at 3:31 PM, TMartin <email address hidden> wrote:

> Question #256417 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/256417
>
> Status: Answered => Open
>
> TMartin is still having a problem:
> Hi Olivier,
>
> I appreciate your quick response, and I understand that this may not be
> a MG5 issue.
>
> I have since tracked down where I think the problem is, and it may
> indeed by a Pythia issue in the end, but I want to explain it to you
> since I have just found out that Pythia 6 is not supported by the Pythia
> people any longer, and Pythia 6 is the version that comes with MG5. If
> you still don't feel that this can/should be resolved in MG5, and that
> this is a Pythia issue, then I will leave you alone.
>
> The problem has to do with the decay table. MG5 calculates the decays
> automatically, but it does it at the parton level. So, for example, an s
> u~ LSP (or even d u~) decay is possible based on the masses of the light
> quarks in the param card. But when this is passed to Pythia, I think
> Pythia tries to hadronize the s and the u~ separately. So it treats them
> as two mesons which have a combined mass larger than the invariant mass
> that is available.
>
> So what I think the problem is is that MG5 treats decays in terms of
> (very) light quarks, but Pythia hadronizes those immediately and thus
> spits out an error due to the masses of the daughters being heavier than
> the mass of the parent. This is why the issue only occurs for the
> compressed spectra scenarios I am experiencing.
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Olivier,

Your second statement is exactly what I think the issue is. You are right, we are using MadWidth outside of its range of validity. This is occurring because we were blindly running an algorithm over a scan of our parameter space.

In the end, we have decided that this won't significantly affect our physics, since the decays are so soft that they will never be observed at the LHC regardless of whether we calculate the widths correctly.

But thanks for getting back to me and confirming that this was the issue. I think a warning would help for future people who might encounter this without thinking about the deeper issues involved.

Thanks again for all your help! We really appreciate it on our end.

Cheers.