Beamspectrum for electron-positron collisions

Asked by Ulrike Schnoor on 2019-07-22

Hello,
what is the status of the implementation of beamspectra for electron-positron collisions in Madgraph? Will it be possible to use CIRCE2 files as input format of the spectrum?
Thanks!
Ulrike

Question information

Language:
English Edit question
Status:
Expired
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
2019-07-31
Last reply:
2019-08-15

This question was reopened

Hi,

The official version of the code does not support such feature.
But we have a parralel version which supports spectrum file as input.
I believe that this is what you are looking for.
You can get such version with the following command line:
bzr branch lp~maddevelopers/mg5amcnlo/maddee

Cheers,

Olivier
> On 22 Jul 2019, at 13:22, Ulrike Schnoor <email address hidden> wrote:
>
> New question #682235 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/682235
>
> Hello,
> what is the status of the implementation of beamspectra for electron-positron collisions in Madgraph? Will it be possible to use CIRCE2 files as input format of the spectrum?
> Thanks!
> Ulrike
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Ulrike Schnoor (ulrike-sch) said : #2

Hi Olivier,
thanks! I will check it out.
Cheers,
Ulrike

Ulrike Schnoor (ulrike-sch) said : #3

Hi Olivier,

I did try that branch (maddee) but I get compilation errors after the 'launch' command[1].
I found that the branch
lp:~maddevelopers/mg5amcnlo/2.5.3_lep
also has the beamstrahlung file option, but it does not work with CIRCE2 files.
What is the recommended way to do it?

Thanks,
Ulrike

[1]
        The compilation fails with the following output message:
            gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c driver.f -I../../Source/
            gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c myamp.f -I../../Source/
            gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c genps.f -I../../Source/
            gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c unwgt.f -I../../Source/
            driver.f:282:132:

                                call DS_add_entry('Helicity',j,ABS(POL(JJ))
                                                                                                                                                1
            Error: Syntax error in argument list at (1)
            driver.f:284:132:

                                call DS_add_entry('Helicity',j,2.0-ABS(POL(JJ))
                                                                                                                                                1
            Error: Syntax error in argument list at (1)
            driver.f:287:45:

                         call DS_set_grid_mode('Helicity',’init')
                                                         1
            Error: Syntax error in argument list at (1)
            driver.f:288:132:

                      else
                                                                                                                                                1
            Error: Unexpected ELSE statement at (1)
            driver.f:294:9:

                   endif
                     1
            Error: Expecting END DO statement at (1)
            driver.f:315:58:

            driver.f:277:132:

                         do j =1,16
                                                                                                                                                2
            driver.f:315:58:

                      write(*,*) 'BW Setting ', (lbw(j),j=1,nexternal-2)
                                                                      1
            Error: Variable ‘j’ at (1) cannot be redefined inside loop beginning at (2)
            driver.f:328:9:

                   end
                     1
            Error: END DO statement expected at (1)
            f951: Error: Unexpected end of file in ‘driver.f’
            makefile:60: recipe for target 'driver.o' failed
            make: *** [driver.o] Error 1
            make: *** Waiting for unfinished jobs....

Let's focus on 2.5.3_lep then (good catch)

What is the difference between the CIRCE2 files and the one expected within that code?
(here I just expect two columns with the values of x1 and x2 for the respective beams)

Cheers,

Olivier

Ulrike Schnoor (ulrike-sch) said : #5

Dear Olivier,

thanks for your reply. I was using the circe2 description which contains a parametrisation of beam spectra - that was in a different format. But I can also plug in files just with x1, x2 of beam-beam events and then it runs.

The resulting cross section differs from the one without beamspectrum, but as a comparison, Whizard with the beamspectrum gives a different cross section.
So to get an idea what is going on I compared running with a beamspectrum file containing only events with x1=x2=0.5, to running at half the center-of-mass energy without beam spectrum. That should give the same result, but it does not: For e+ e- > mu+ mu- with default cuts, the case sqrts=1.4TeV and x1=x2=0.5 gives 85 fb while sqrts=700GeV without beamspectrum gives 213 fb. What is the reason for this: does x1=x2=0.5 in each beam event not mean the same as running at half the COM energy? (In Whizard, it does.)

A somewhat related question: For ISR, is it still state of the art to use this package: https://github.com/qliphy/MGISR ?

Thanks,
Ulrike

Did you set lpp1 and lpp2 to 0 ?

Looks like that branch is using some weird ISR mode by default (I would certainlty not recomend to use those actually)

Cheers,

Olivier

> On 30 Jul 2019, at 10:27, Ulrike Schnoor <email address hidden> wrote:
>
> Question #682235 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/682235
>
> Status: Answered => Open
>
> Ulrike Schnoor is still having a problem:
> Dear Olivier,
>
> thanks for your reply. I was using the circe2 description which contains
> a parametrisation of beam spectra - that was in a different format. But
> I can also plug in files just with x1, x2 of beam-beam events and then
> it runs.
>
> The resulting cross section differs from the one without beamspectrum, but as a comparison, Whizard with the beamspectrum gives a different cross section.
> So to get an idea what is going on I compared running with a beamspectrum file containing only events with x1=x2=0.5, to running at half the center-of-mass energy without beam spectrum. That should give the same result, but it does not: For e+ e- > mu+ mu- with default cuts, the case sqrts=1.4TeV and x1=x2=0.5 gives 85 fb while sqrts=700GeV without beamspectrum gives 213 fb. What is the reason for this: does x1=x2=0.5 in each beam event not mean the same as running at half the COM energy? (In Whizard, it does.)
>
> A somewhat related question: For ISR, is it still state of the art to
> use this package: https://github.com/qliphy/MGISR ?
>
> Thanks,
> Ulrike
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Ulrike Schnoor (ulrike-sch) said : #7

Hi Olivier,
yes, both lpp1 and lpp2 are set to 0.
Is there a way to remove that ISR mode, or is there another branch that does not have it, but does have the beamstrahlung?
Thanks,
Ulrike

Launchpad Janitor (janitor) said : #8

This question was expired because it remained in the 'Open' state without activity for the last 15 days.