Parameter epa_q_max has no influence on the process integration/generation

Asked by Aleksander Filip Zarnecki on 2019-12-24

Dear Authors,

This question is related to the previous one concerning beam polarisation settings in EPA. I look at the process:
     process aeqqn = A, E1 => ( quark, QUARK, N1 )
with beam defined as:
    beams = e1, E1 => circe2 => epa, isr
The starting EPA settings are:
  epa_x_min = 0.001
  epa_mass = me
  epa_q_min = 0.001 GeV
  epa_q_max = 1 GeV
I then tried to check how the cross section changes when changing epa_q_max (to 10 GeV or 100 GeV). It turned out that there is no change in the cross section at all, also the kinematic distributions seem unchanged. The Q_max cut is crucial to avoid double counting with the corresponding e+e- process (where we make a corresponding Q_min cut). How can I solve this problem?

Moreover, the distribution of Q value calculated from the outgoing electron (taken from the event record) shows that there are no restrictions on Q value (it changes from 10^-5 to sqrt(s)). This could be related to the way electron recoil is generated...

I am using WHIZARD version 2.8.2, same results are also for version 2.7.0.

I will be grateful for your help

Question information

English Edit question
WHIZARD Edit question
Simon Braß Edit question
Solved by:
Simon Braß
Last query:
Last reply:
Launchpad Janitor (janitor) said : #1

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

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

still open. Came over Christmas holidays

Launchpad Janitor (janitor) said : #3

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

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

We still need a bit more time.

Simon Braß (sbrass) said : #5

Dear Filip,

I'm very sorry for the delayed answer.

EPA_Q_MAX is not used for the setup of the beam EPA, instead, it is only used to steer the event generation (with EPA).
The dependency can be changed by using epa_e_max (see whizard.pdf, pp. 1529 for the implementation details of beam EPA), with that you will see a change in the size of cross section.

I've tested this only so far for epa_e_max ∈ [1, 100] GeV.
For the first, if you want to use it, you will have to explicitly declare it by "real epa_e_max = 1 GeV" (note the >real<).

Internal note: The variable epa_e_max is neither referenced in the manual, nor in variables.nw.
It gets only referenced in beams.nw:dispatch_sf_data (and somewhere in rt_data.f90).
One has to explicitly declare the variable in Sindarin.
We have to cleanup it by either using epa_q_max or adding epa_e_max to the variables' list (and to the manual).


Dear Simon,

Thank you for detailed explanation. Unfortunatly, my observation is that epa_q_max does not change the kinematic distributions either. But this is not the key problem.

The main problem is that I want to generate (and have the reliable cross section value) for the process like:
    e+e- -> e- nubar u dbar
The main contribution is due to gamma-W fusion, where gamma can be virtual or quasi-real.
For virtual gamma, we use WHIZARD for reaction (corresponding to the one written above):
     process qqen1 = e1, E1 => ( e1, N1, u, D )
and (so far) we applied the generator level cut on the photon virtuality (above 4 GeV)
     all M < - default_Q_cut [incoming e1, e1]

The plan was to generate the remaining part of the phase space (real and quasi-real photons, up to virtuality of 4 GeV) with EPA, by setting epa_q_max = 4 GeV for the process:
     process qqen2 = A, E1 => ( u, D, N1 )

If this variavle is not used, how to generate these two processes properly, so to have the correct cross section estimate and avoid double counting? Your suggestion would be very helpful!


Best Simon Braß (sbrass) said : #7

Dear Filip,

thanks for your clarifications, the physics case is so far clear to me.

I've linked your question to a bug report, where I summarized again my findings.
So far, you've used WHIZARD correctly, however, the option `epa_q_max` was not correctly set/used within WHIZARD, i.e. the variable was not correctly given to the beam handling.

I've committed the appropriate changes; a fresh WHIZARD tarball (be careful, as it is only a nightly tarball, i.e. a snapshot of the development version) will be available tomorrow on

WHIZARD should then produce the correct results.


Thanks Simon Braß, that solved my question.