radiative Bhabha scattering

Asked by Ulrike Schnoor on 2019-10-15

Dear Whizard authors,

we want to generate events for the process ee-> ee gamma, which is a background to monophoton signatures if both of the electrons are either very soft or stay in the beam pipe. This means ideally no cuts can be placed on the electrons, only on the photon. Requirements on the photon do also bias the electron kinematics a bit, but nevertheless we do not get a convergence with Whizard if no electron cuts are applied. I think this is expected because there are singularities which are only cancelled at higher order.
How can we know in a well-defined way what is the part of the cross section we are missing when we apply cuts on the electrons? Can we generate a sample with a cut on the electron theta and energy that removes the singularity and still be somewhat sure that we are not missing too much of a contribution? Is there a way to get the higher order in Whizard or do you know some other tool that can do it?

An example sindarin can be found here:
https://cernbox.cern.ch/index.php/s/1i3EFSz0BGS6ftS

Thanks for any advice!
Ulrike & Philipp & Jean-Jacques

Question information

Language:
English Edit question
Status:
Solved
For:
WHIZARD Edit question
Assignee:
Wolfgang Kilian Edit question
Last query:
2020-03-13
Last reply:
2020-04-07
Wolfgang Kilian (whkilian) said : #1

Hi Ulrike, after several tests, here is how to approach this:

(1) With such low Q^2 at high energy, double-precision numerics is insufficient. Numerical noise dominates the results.

You may use either quadruple precision (16byte) or extended precision (10byte) instead. The former is safe, but it is an order of magnitude slower, at least. The latter (currently only available for gfortran) is as fast as double, but with less precision than quadruple. From my tests, extended seems to be sufficient, but the results can always be cross-checked with quadruple.

This has to be set when configuring whizard before compilation: --with-precision=extended or --with-precision=quadruple. You need a separate executable, switching precision at run-time is not possible.

(2) Since the typical Q^2 values for this process can become very small, convergence of the phase-space adaptation is somewhat improved by setting
    phs_q_scale = 1e-4 GeV
(or so, default is 10 GeV)

There is also phs_e_scale (default 10 GeV) to consider. In the example, the photon energy cut is 10 GeV, so the default should be fine.

(3) With extended precision and phs_q_scale, you may verify that the results converge reasonably well if CIRCE2 is switched OFF. (I.e., only ISR). To check this, I used 30 iterations with 100k calls each. Fewer iterations may be sufficient.

(4) If you switch CIRCE2 ON again, the results do not converge that well. Apparently, the generator mode of CIRCE2 prohibits precise adaptation to this extreme phase space. Nevertheless, the setup should yield a useful result and event samples, albeit with low efficiency. (You may consider doing the study without beamstrahlung first and only later assess the perturbation effect of adding beamstrahlung.)

Wolfgang Kilian (whkilian) said : #2

A possible cause: the momenta generated by the CIRCE module inside WHIZARD are apparently massless, even if the original beam momenta were massive. For almost all physics questions, this property is irrelevant. Here, it might have lead to the observed divergence.

It may be necessary to review the handling of particle masses vs. structure functions/spectra.

Wolfgang Kilian (whkilian) said : #3

There is an additional question whether ISR should be convoluted with the process.

In the vicinity of the Coulomb singularity (which this process has if the matrix-element photon is soft/collinear), the ISR approximation by a structure function is questionable at best. The ISR approximation requires switching the electron from space-like (exact ME) to time-like (factorized) in a region where the amplitude has a power-like dependence on the offshellness.

Apart from the CIRCE problem mentioned above, it appears as if any extra photons have to be generated explicitly here, and ISR should remain switched off altogether.

Juergen Reuter (j.r.reuter) said : #4

The open issue now seems to be the bad convergence when CIRCE2 is used for Bhabha or radiative Bhabha. This was mainly due to the reason that CIRCE2 explicitly turned over massless electrons to the hard matrix element. This has been corrected now, committed in svn, public git and nightly builds. It will be released in v2.8.3 and v3.0.0beta. Ulrike wants to test the new configuration and report back about the stability. If it does the job, this will be marked as `solved`.

Ulrike Schnoor (ulrike-sch) said : #5

Thanks for the reply and for providing the fix for the CIRCE2 issue. Jean-Jacques will test the beamstrahlung with the current nightly.
However, it is not the only remaining issue. We are also seeing that in the case without beamstrahlung/CIRCE2, there is an impact of the cut M(e_in,e_out)>sqrt(2)*m_e. Normally this should not have an impact for massive electrons. Jean-Jacques has sent the relevant Sindarin files to Wolfgang for investigation.

Wolfgang Kilian (whkilian) said : #6

@Ulrike,
yes, I know. That's the next item on my list. You're right that the issue is still open.

Ulrike Schnoor (ulrike-sch) said : #7

Hi all,
Jean-Jacques has checked the CIRCE2 issue in the current nightly and confirms that it is fixed. The value in Table 5 of Jean-Jacques' summary
https://indico.cern.ch/event/891657/contributions/3760745/attachments/2000950/3340066/Wh2n1N1aAnde1E1a.pdf
for TFF, no cuts, goes from 461 pb to 186 pb. Thanks for fixing this bug!

However, the other numbers are unchanged so there are still the following two issues remaining:
1. the impact of the M(e_in,e_out)>m_e cut which should not change the cross section, but does change it (as mentioned in my last reply #5) - see also page 3 of https://indico.cern.ch/event/891657/contributions/3760745/attachments/2000950/3340387/e1E1a_sm_FFF_poL0_cutsHistNNPtTh7_C2_380.pdf
2. the mass of the incoming electron in the case of ISR recoil switched on is zero (as you can see on page 1 of
https://indico.cern.ch/event/891657/contributions/3760745/attachments/2000950/3340402/e1E1a_sm_FTT_poL0_cutsHistNNPtTh7_C2_380.pdf).
Jean-Jacques has confirmed that this is still the case with the 2.8.3 nightly of today.

Let us know if we can do any other checks or provide more information and also in case I should open a new question or bug report.

Wolfgang Kilian (whkilian) said : #8

OK, summarizing the above and my recent e-mail:

I understand that switching on/off beamstrahlung doesn't have a big effect anymore.

1. I now think that such a cut will have a significant impact, because a fraction of the real cross section (recall: visible photon, but invisible electron and positron) should have a lower M value. The WHIZARD result might be correct after all, up to higher orders of course.

2. OK, this is a completely different issue.

Wolfgang Kilian (whkilian) said : #9

Update, summarizing again:

1. Regarding the results without BS or ISR, I don't see a handle to change anything as soon as the cuts are fixed. Kinematics appears consistent. There are events with momentum transfer significantly below the electron mass, and this seems to be correct. For precise kinematics over the complete phase space, one has to use WHIZARD compiled with extended precision (at least), even for LEP energy.

2. With ISR, that conclusion is unchanged for the cross section, where no photon recoil is implemented. WHIZARD provides no straightforward means (yet) to avoid double-counting for ISR vs ME photons, but does not exclude to merge event samples manually, if appropriate cuts are applied.

3. For the generated event sample (with isr_handler for recoil), I changed the code so that the intermediate 'incoming' electron is kept massive by default. This unphysical particle was massless before, which led to some confusion. [Code will appear in the production branch soon.]

4. For WHIZARD's internal analysis tools, I'd prefer to use the 'beam' prefix for the beam electrons, not 'incoming'. The latter keyword denotes the parton after radiation and immediately before scattering. This is useful for technical studies but not really a physical particle. The 'beam' electron is the electron before ISR.

5. Switching on beamstrahlung (CIRCE2), the program has been fixed so that the electrons are also kept massive by default. Numerical stability/convergence might still be an issue though, this has to be tested.

Juergen Reuter (j.r.reuter) said : #10

Ulrike confirmed in her email on April 7 that Jean-Jacques and she went through the calculations and agreed, so they can now continue with a prescription for their monophoton analysis.