mediator not present in output

Which PDF did you use?

If you do not use PDF, then the invariant mass of the mu+ mu- will be the energy of the collision.
In that case the Z or Zp is likely consider off-shell (depending of such energy) and therefore not written in the lhef output file.

With PDF, you do have a competition between the energy of the beam (highly favor by the PDF) and the resonance (favored by the matrix-element).
So depending of the energy of the beam sometimes one or the other is dominant.

Cheers,

Olivier

> On 6 Mar 2023, at 08:15, Yehia Abdelaziz <email address hidden> wrote:
>
> New question #705729 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/705729
>
> I am trying to generate the process e+ e- > zp > mu+ mu- in the model http://feynrules.irmp.ucl.ac.be/wiki/B-L-SM#no1 and using electron positron collider run parameters. But the resulting lhe file doesn't contain a zp and also the invariant mass distribution of the dimuons is very narrow.
>
> Also If I did the same process with Z instead of Zp in a sm process, I get the same result. Is this a problem with electron positron colliders in Madgraph?
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Thank you very much Olivier.
I initially chose the lpp=0 (No pdf) option since it is a lepton collider and I assumed there is no pdf. But how can I specify the pdf for lepton colliders in madgraph?

Hi,

The PDF of the electron is very close to a delta function indeed.
So depending of the energy of the accelerator, we can (or not) use lpp=0 reliably.
For accurate description of the physics, this is off course quite mandatorry.

They are two main effects that we include in the PDF, ISR (of photon) and beam-beam interaction (beamstrahlung), while the first is universal the second depend both on the energy and the type of accelerator (linear or circular).

Typically the help command and/or auto-completion is your friend

>set pdlabel
cepc240ll cteq6_m eva isronlyll nn23lo scale
chff cteq6l1 fcce240ll iww nn23lo1
clic3000ll default fcce365ll lhapdf nn23nlo
cteq6_l edff ilc500ll mixed none
Where you can see a lot of PDF that are for electron collider.
If you do not have the accelerator/energy that fit your case, you can use the isronlyll which does not have that second effect.

Cheers,

Olivier

> On 7 Mar 2023, at 08:45, Yehia Abdelaziz <email address hidden> wrote:
>
> Question #705729 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/705729
>
> Status: Answered => Open
>
> Yehia Abdelaziz is still having a problem:
> Thank you very much Olivier.
> I initially chose the lpp=0 (No pdf) option since it is a lepton collider and I assumed there is no pdf. But how can I specify the pdf for lepton colliders in madgraph?
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

So to include isr only, the pdlabel should be isronlyll. While for isr+bremstrahlung for the ilc at 500 GeV I need to choose ilc500ll is that correct?

Also for the beam type it is written in arxiv:2108.10261 that lpp1 and lpp2 should be 3/-3 to include isr and bremstrahlung effects. But when I try do that it gives an error : Survey returns zero cross section.

The zero cross section error was fixed by setting lpp1 to -3 and lpp2 to 3 (not the opposite).

The run card is as follows:

set ebeam1 250
set ebeam2 250
set pdlabel ilc500ll
set lpp1 -3
set lpp2 3

Everything works fine but pythia doesn't run and gives the following error:

ERROR: Parton-Shower are not yet ready for such proton component definition. Parton-shower will be switched off

Hi,
Could you please tell me how to solve this error :
ERROR: Parton-Shower are not yet ready for such proton component definition. Parton-shower will be switched off

Thanks

Hi,

This is a current limitation of the code and it's interface to parton-shower.
We actually need someone that understand what format parton-shower expect in this case and change our code to match that format.

Cheers,

Olivier

Thanks Olivier,
Isn't there any work around this that you can suggest to solve this problem?

Hi Yehia,

I do not know a work-around here. I know that this is technically possible to implement.
In principle, pythia8 has a convention to distinguish between ISR and beamstralunhg such that they are able to distinguish them.
Now the issue is that we do not distinguish them in our code, so what someone has to do is
1) find a way to separate the two contributions from the convolution of both.
2) find the pythia8 convention and change the way to write the event to match the convention
3) find if pythia8 needs some additional tuning in the options parameter to have a sensible setup of the parton-shower.

@Marco, did you look at something like that for the NLO part of the code within 3.5.0? Or is it fixed order computation?

Hi,
So, first, run without parton shower. Then, you may not see the mediator in the event file because you are away from its mass.
What are the mass, widths? What is the center of mass energy?
Because if abs(mass - energy) > bw_cutoff * width then the resonance is not written in the event file, if I am not mistaken

Best wishes,

Marco

Hi Olivier,

> On 16 Mar 2023, at 17:05, Olivier Mattelaer <email address hidden> wrote:
>
> Question #705729 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/705729
>
> Olivier Mattelaer posted a new comment:
> Hi Yehia,
>
> I do not know a work-around here. I know that this is technically possible to implement.
> In principle, pythia8 has a convention to distinguish between ISR and beamstralunhg such that they are able to distinguish them.
> Now the issue is that we do not distinguish them in our code, so what someone has to do is
> 1) find a way to separate the two contributions from the convolution of both.
> 2) find the pythia8 convention and change the way to write the event to match the convention
> 3) find if pythia8 needs some additional tuning in the options parameter to have a sensible setup of the parton-shower.
>
>
> @Marco, did you look at something like that for the NLO part of the code within 3.5.0? Or is it fixed order computation?
this is FO only

Cheers,

Marco
>
> --
> You received this question notification because you are assigned to this
> question.