errors in ep colliders when running Pythia6

We do not have the framework for having dynamical pythia_card in function of the process.

Cheers,

Olivier

I should also add some more comments on Pythia6,
The place that it appears to be intolerable rounding errors is in pyremn.f, in your Pythia-PGS package. Near line 320, there is

     IF(PMIN(0)+PMIN(1)+PMIN(2).GT.VINT(1).OR.(MINT(45).GE.2.AND.
     &PMIN(1).GT.PSYS(1,4)).OR.(MINT(46).GE.2.AND.PMIN(2).GT.
     &PSYS(2,4))) THEN
        MINT(51)=1
        MINT(57)=MINT(57)+1
        RETURN
      ENDIF
.
The problem appears in PMIN(1).GT.PSYS(1,4) and PMIN(2).GT.PSYS(2,4). PSYS(...) sometimes is 0.00000000000000000, however PMIN(...) are 10^{-16}. I think it is a rounding error. If you would like to conserve the function of the Pythia6.4 to do photon showering of the initial electrons/positrons, I suggest you fix these lines by adding up tolerance of the rounding errors. e.g., PMIN(1).GT.PSYS(1,4)+1d-9, etc., although I did not make a test on this modification, so this is just a suggestion.

Although you decide not to fix it, I still would like to instruct that it is fairly easy to fix the problem. You can modify your Pythia-pgs package. In fact, when I read this, I found that long times ago, when you wrote the ME2....f file, in the subroutine UPINIT, you were aware of the fact that e+e- colliders are different from ep colliders so you modified MSTP(51) when ee colliders are detected. You might just add one more IF...ENDIF in order to modify MSTP(11) when ep cases are encpuntered. I think this is a simple modification, although to pythia–pgs rather than madgraph itself.

oh, sorry, a typo. I mean you were aware of the difference between e+e– colliders and pp colliders when you wrote the subroutine UPINIT in ME2....f in pythia-pgs, not ep colliders. I just suggested you to add another block to deal with ep colliders.

Hi,

If you provide to me a patch to pythia-pgs,
I will be more than happy to apply it.

Cheers,

Olivier

On 17 Jun 2015, at 17:23, tang yilei <email address hidden> wrote:

> Although you decide not to fix it, I still would like to instruct that
> it is fairly easy to fix the problem. You can modify your Pythia-pgs
> package. In fact, when I read this, I found that long times ago, when
> you wrote the ME2....f file, in the subroutine UPINIT, you were aware of
> the fact that e+e- colliders are different from ep colliders so you
> modified MSTP(51) when ee colliders are detected. You might just add one
> more IF...ENDIF in order to modify MSTP(11) when ep cases are
> encpuntered. I think this is a simple modification, although to
> pythia–pgs rather than madgraph itself.
>
> --
> You received this bug notification because you are subscribed to
> MadGraph5_aMC@NLO.
> https://bugs.launchpad.net/bugs/1466119
>
> Title:
> errors in ep colliders when running Pythia6
>
> Status in MadGraph5_aMC@NLO Generator:
> Won't Fix
>
> Bug description:
> This bug is related to my previous question entitled the same.
> I have been aware of the reason. That is because Pythia6 set MSTP(11)=1 as a default. According to Pythia6's mannual http://cepa.fnal.gov/psm/simulation/mcgen/lund/pythia_manual/pythia6.4/lutp0613man2.pdf, Page194, MSTP(11)=1 means that "electron carries only a fraction of beam energy in agreement with next-to-leading electron parton-distribution function, thereby including the effects of initial-state bremsstrahlum". However, when doing so, it seems that pythia6 is trying to shower the electrons and then there are then intolerable rounding errors in the programs flow, e.g., 10^-16 != 0 so that pythia reported an error. Therefore, it is convenience to set MSTP(11)=0 in the pythia-card in order to avoid this problem, or to make some further modifications of the MadGraph or Pythia6.
>
> Totally speaking, I suggest you add an extra line MSTP(11)=0 as
> default in pythia-card, or modify MSTP(11)=0 when doing e-p collisions
> just after the initializing process in pythia.f
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/1466119/+subscriptions

Dear professors,

The attachment is the patch I've wrote. One is the ME2pythia.f. Line 190-198 is add by me. It closed MSTP(11) when a leptonic-hadronic collider is detected. The other is pyremn.f, I've modified Line-324-337, in which the tolerance of errors are added.

You should ether apply ME2pythia.f or pyremn.f without using both of them. The modification of pyremn.f involves directly modifying the Pythia-6.4 core code so I am not confident with this modification, so I suggest you apply my vertion of ME2pythia.f in this stage. One should pay the price of being unable to do leptonic photon showering by applying ME2pythia.f. I also consulted the authors of Pythia-6.4, asking them whether my modification of pyremn.f is reliable and correct, but they have not reply on it yet.

By trying to modify the MSTP(11) settings, I have new discoveries about this bug. In the unweighted-events lhe file, I've found such lines in the case of the ep-collider,

<init>
       11 2212 0.10000000000E+04 0.10000000000E+04 0 0 247000 247000 3 1
  0.33142499800E+03 0.51965215720E+01 0.33143000000E+01 0
<generator name='MadGraph5_aMC@NLO' version='2.2.3'>please cite 1405.0301 </generator>
</init>
.

Notice the two 247000 in the second line, it is the PDFset that you will pass to PDFSUP(2) variables inside the UPINT subroutine in Pythia-pgs. In the case of pp collider, these are
<init>
     2212 2212 0.65000000000E+04 0.65000000000E+04 0 0 247000 247000 3 1
  0.72515700000E+09 0.58016650000E+07 0.70920000000E+07 0
<generator name='MadGraph5_aMC@NLO' version='2.2.3'>please cite 1405.0301 </generator>
</init>
,
and
<init>
      -11 11 0.65000000000E+04 0.65000000000E+04 0 0 0 0 3 1
  0.30648105000E-02 0.54441307500E-04 0.31194000000E-04 0
<generator name='MadGraph5_aMC@NLO' version='2.2.3'>please cite 1405.0301 </generator>
</init>
for e+e- collider.

I think in the case of ep collider, the proper line should become
<init>
       11 2212 0.10000000000E+04 0.10000000000E+04 0 0 0 247000 3 1
  0.33142499800E+03 0.51965215720E+01 0.33143000000E+01 0
<generator name='MadGraph5_aMC@NLO' version='2.2.3'>please cite 1405.0301 </generator>
</init>
.

However, this modification on unweighted_event.lhe does not seem to work. It may involve the
      IF(PDFSUP(1).NE.19070.AND.(PDFSUP(1).NE.0.OR.PDFSUP(2).NE.0))THEN
c Not CTEQ5L, which is standard in Pythia
         CALL PYGIVE('MSTP(52)=2')
c The following works for both PDFLIB and LHAPDF (where PDFGUP(1)=0)
c But note that the MadEvent output uses the LHAPDF numbering scheme
        IF(PDFSUP(1).NE.0)THEN
           MSTP(51)=1000*PDFGUP(1)+PDFSUP(1)
        ELSE
           MSTP(51)=1000*PDFGUP(2)+PDFSUP(2)
        ENDIF
      ENDIF
lines in the ME2pythia.f. However, I have no idea about the PDFs' settings both MadEvents and Pythia6, so I don't know how to fix it. I think a complete solution of this bug should consider all of the issues I have mentioned, including modifying the MadEvent itself.

Yi-Lei Tang

Oh, sorry, I meant, if you applied my ME2pythia.f, you should pay the price of being unable to do the photon-showering of the initiate-state leptons, not the photon-showering of all the leptons.

Hi,

Being unable to do photon-showering of the initiate-state leptons
seems something very bad in general.
So I think that it is dangerous to hardcode such modification in a code.

When such behaviour are needed (like in your case) the user need to be aware of it.
And therefore the best is to have the user to modify the pythia_card.dat.
So I really think that the best solution is to not modify anything in a automatic/hidden way.

Hopefully this thread will help people having the same issue in the future.

Cheers,

Olivier

On 19 Jun 2015, at 04:59, tang yilei <email address hidden> wrote:

> Oh, sorry, I meant, if you applied my ME2pythia.f, you should pay the
> price of being unable to do the photon-showering of the initiate-state
> leptons, not the photon-showering of all the leptons.
>
> --
> You received this bug notification because you are subscribed to
> MadGraph5_aMC@NLO.
> https://bugs.launchpad.net/bugs/1466119
>
> Title:
> errors in ep colliders when running Pythia6
>
> Status in MadGraph5_aMC@NLO Generator:
> Won't Fix
>
> Bug description:
> This bug is related to my previous question entitled the same.
> I have been aware of the reason. That is because Pythia6 set MSTP(11)=1 as a default. According to Pythia6's mannual http://cepa.fnal.gov/psm/simulation/mcgen/lund/pythia_manual/pythia6.4/lutp0613man2.pdf, Page194, MSTP(11)=1 means that "electron carries only a fraction of beam energy in agreement with next-to-leading electron parton-distribution function, thereby including the effects of initial-state bremsstrahlum". However, when doing so, it seems that pythia6 is trying to shower the electrons and then there are then intolerable rounding errors in the programs flow, e.g., 10^-16 != 0 so that pythia reported an error. Therefore, it is convenience to set MSTP(11)=0 in the pythia-card in order to avoid this problem, or to make some further modifications of the MadGraph or Pythia6.
>
> Totally speaking, I suggest you add an extra line MSTP(11)=0 as
> default in pythia-card, or modify MSTP(11)=0 when doing e-p collisions
> just after the initializing process in pythia.f
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/1466119/+subscriptions

Hi,
  If no hard code is modified, I think it is convenient to add a comment line in the default pythia-card at least, in order to let the users know why and how, and choose themselves. I may look into the pythia6.4 code in the future and if I can make a reliable modification to the codes, I will send patches to you.

Yi-Lei Tang