EpIC: novel Monte Carlo generator for exclusive processes

Abstract

We present the EpIC Monte Carlo event generator for exclusive processes based on generalised parton distributions. EpIC utilises the PARTONS framework, which provides a flexible software architecture and a variety of modelling options for the partonic description of the nucleon. The generator offers a comprehensive set of features, including simulation of a variety of exclusive processes and radiative corrections. It may be used both in the analysis of experimental data, as well as for impact studies, especially for the future electron-ion colliders.

1 Introduction

The objective of this study is to develop a Monte Carlo event generator for exclusive processes with the target hadrons remaining intact during the coherent interactions with high-energy leptons. The factorisation theorems developed in the framework of quantum chromodynamics (QCD) allow one to describe such processes in terms of non-perturbative generalised parton distribution functions (GPDs) [1,2,3,4,5] convoluted with perturbatively calculable hard scattering parts of the amplitude.

GPDs are universal, process-independent functions that parametrise the off-forward nucleon matrix elements of quark and gluon bilinear operators with light-like separations. In case there is no momentum transfer to the nucleon, i.e. in the forward limit, certain GPDs reduce to the collinear parton distribution functions (PDF). Moreover, the first Mellin moments of GPDs are related to elastic form factors [2]. In this regard, GPDs may be viewed as a unified concept of elastic form factors studied through elastic scattering processes and one-dimensional PDFs studied via (semi-) inclusive scattering processes. Another key aspect of GPDs is their relation to nucleon tomography. The Fourier transforms of GPDs are related to the impact parameter space distributions when there is no collinear, but instead finite transverse momentum transfer to the nucleon [6,7,8]. Through the impact space distributions, GPDs provide information on parton distributions in the transverse plane to the motion of the nucleon, thereby enabling nucleon tomography, the visualisation of the three-dimensional structure of the nucleon, which involves the correlation between impact parameter space distribution functions, parton polarization, and the longitudinal momentum fractions carried by partons. GPDs also exhibit a unique relationship with the energy-momentum tensor (EMT) form factors, which encode fundamental properties of the nucleon, such as mass and spin decomposition of the nucleon into its constituent parts (including orbital angular momentum) [2, 3, 9] as well as its internal structure based on the so-called “mechanical” forces that contain information about the distribution of pressure and shear forces within the nucleon [10,11,12]. For more information on GPDs, we refer to the available reviews on the subject, such as Refs. [13, 14].

The extraction of GPDs from data measured in exclusive processes is not an easy task, mainly due to the difficulty of solving an inverse problem. There are typically different types of GPDs involved in a process, and they each need to be deconvoluted from the process amplitude. In order to accomplish this, data measured in many different types of exclusive processes are needed with a wide range of kinematic coverage. To this end, measurements of exclusive processes have been performed at several facilities, such as DESY, JLab, and CERN. GPDs constitute also the pillars of the scientific programmes for the next generation of machines. This includes both electron-ion colliders, EIC [15, 16], EIcC [17] and LHeC [18], and fixed target experiments at CERN [19] and JLab [20].

As part of this global effort, we have developed a Monte Carlo (MC) generator called EpIC, whose logo appears in Fig. 1. The EpIC generator features a novel architecture using a modular programming approach. In this way, the code structure is kept as simple as possible and the addition of new developments, such as new channels or algorithms to generate random numbers, is made as easy as possible. The architecture of EpIC, including the nomenclature for naming its elements, is based on the PARTONS framework [21]. PARTONS is also used to evaluate the Born cross-section for a given process, which is used to generate MC events after the inclusion of radiative corrections (RCs).

Fig. 1

Logo of the project

EpIC can generate events for a number of exclusive processes. The following are available at the time of writing this paper: deeply virtual Compton scattering (DVCS), time-like Compton scattering (TCS), and deeply virtual meson production (DVMP) of $\pi ^0$ and $\pi ^+$ mesons. In this article, we choose DVCS whenever an exemplary process is needed. Adapting to other processes is straightforward and typically only requires replacing the acronym, e.g. the equivalence of DVCSGeneratorService for TCS is TCSGeneratorService. EpIC, as in the case of PARTONS, follows the so-called Trento convention [22] for the definition of e.g. scattering angles.

The purpose of this article is to provide a reference and document the structure and functionality of EpIC. We will focus on the explanation of the architecture, starting with a brief description of the PARTONS framework in Sect. 2, which is crucial to understand the technical aspects of EpIC. In Sect. 3, we present the architecture of EpIC. In particular, we list all types of modules and show the relation between them. The user interface is introduced in Sect. 4, while the generator’s performance is demonstrated in Sect. 5. The summary is given in Sect. 6. In the appendix (Appendix A), we review the basics of the radiative corrections and explain how to compute them in the collinear approximation. The purpose of this appendix is to help users to familiarise themselves with the parameters of radiative corrections used in EpIC.

EpIC is written in the C++ programming language. The code can be accessed at the GitHub platform [23] and is distributed under the GPL 3.0 licence. The project’s webpage, Ref. [24], includes information such as a technical documentation of C++ classes, a guide on how to compile the code, and an example code for users.

2 PARTONS framework

PARTONS (PARtonic Tomography Of Nucleon Software) [21] is a software framework for studying the 3D structure of hadrons. It provides essential tools for QCD phenomenology and allows one to compute observables from models describing non-perturbative objects. For instance, it includes various models of GPDs and methods to perform their pQCD evolution. It also includes methods to evaluate amplitudes and cross-sections for a variety of exclusive processes, such as DVCS and TCS, described at LO and NLO of pQCD precision. The framework can be used in analyses to predict observables from existing models, see e.g. Refs. [16, 17, 25], but also to constrain new models from available experimental data [26, 27]. Because of its versatility, the framework can also act as a laboratory for studying new concepts for phenomenology, like new ways of modelling, see e.g. Refs. [28,29,30].

The architecture of PARTONS utilises a modular programming approach. The central role in this architecture, which has also been adopted in EpIC, is played by the modules. A module is a single encapsulated development of a given type, for instance a single GPD model. The only purpose of modules is to provide data for a specific input, like values of GPDs for a given GPD kinematics. The construction of modules utilises both the inheritance and polymorphism mechanisms of C++. Therefore, the development of new modules is remarkably straightforward, as developers need only to provide their code related to the developments they are interested in and adapt it to the predefined classes in the framework. We demonstrate this with the example of module, which is used to implement the Goloskokov–Kroll (GK) GPD model [31,32,33], from the PARTONS library. The following is an excerpt from the header file:

where only the most relevant members of the class are shown, some of which will be discussed further in this section. The purpose of the module is to evaluate the values of GPDs. This task is predefined in , being in terms of inheritance the parent class of . The predefinition means here the declaration of a virtual function, so that each of the derived classes ( , , ...) have a function of the same signature among its members, but the actual implementation of this function in those classes is, in general, different. The evaluation of GPDs takes place, for instance, in the following function:

The function returns a container that stores the numerical values of twist-2 GPD H, including its singlet, $H^{(+)}$, and non-singlet, $H^{(-)}$, combinations, as defined in Ref. [13]. The input GPD kinematics is accessible in the body of the function via the , , , and variables, which are defined in the class. Those variables correspond to the GPD variables x, $\xi$, t, $\mu _\mathrm {F}^2$, and $\mu _\mathrm {R}^2$, respectively, as introduced in Table 1. They are set when one evaluates GPDs via , which is also defined in . As one may see in our example, quark flavours and GPD types are distinguished by and enums, respectively, while inputs and outputs are encapsulated in the , and containers.

Table 1 The variables used in evaluating GPDs

A single instance of each module is loaded into memory at the beginning of the program execution, namely when static constant variables are initialised. The addresses of such instances are stored by the registry, which later acts as a phone book, allowing one to access the instances by either their IDs or defined names. We demonstrate this mechanism with the following example:

When the program starts, is initialised with a unique ID assigned by the registry ( class being a singleton). During this process, the registry takes and stores the address of each new instance. All modules inherit from the same basic class called , allowing the registry to store addresses of the same type of objects. The constructor of requires a unique string of characters that is used as a human-readable name of the module.

The registry stores addresses of single instances of pre-configured modules. Users may get copies of those instances by using the factory (also being a singleton), for instance:

The registry and factory are the key architectural ingredients, which allow users to add an unlimited number of new modules in the PARTONS architecture, without having to modify existing modules.

There are many types of modules, but one may configure all of them, i.e. pass additional information to the modules, in a generic way, avoiding, for instance, the static casting. This is possible thanks to the virtual functions, which developers may use to allow transferring additional parameters to modules. For instance:

can be used to set variable to 1 in the following way:

where is the unique name of the parameter. The way of supplying modules with additional parameters presented here plays a crucial role in constructing the user interface (UI).

To avoid “manually” repeating some tasks, the services are used. In this way, users can perform complex tasks in a straightforward and robust manner by hiding the complexity of low-level functions. The services link such tasks as parsing input files, running many computations, employing multi-threading computing, filling the database, printing the output to the screen etc. Without services, all those tasks would have to be done explicitly by users, requiring a profound knowledge of the functioning of the project. This way of working would also be time consuming and vulnerable to mistakes.

3 EpIC’s architecture

The generic architecture of the generator, including the flow of data transferred between the modules, is shown in Fig. 2. Each module takes input data, processes it according to predefined tasks, and returns the corresponding output. The actual implementation of some types of modules depends on the simulated process. For instance, is the parent class for and , which are used for DVCS and TCS processes, respectively. These two types of modules process data according to the same task predefined in , but they use different inputs. It is either DVCS or TCS kinematics. Because of this difference, has been developed as a C++ template, allowing and to handle input containers of various types. With those templates, the addition of new processes to the generator is as easy as possible. and are used as base classes for actual modules, where specific physics developments are encoded. In Fig. 3 we present the entire tree of inheritance for modules of type.

Below, we provide a brief description of each type of module and its purpose. Additionally, we indicate whether the actual implementation of modules of a given type depends on the simulated process. This information is useful in recognising which parts of the generator need to be extended when a new process is added to the generator.

Fig. 2

Sketch showing the generic architecture of the project, i.e. without specifying the corresponding physics process for some modules. Details are provided in the text

Fig. 3

Inheritance tree of modules used for the implementation of radiative corrections. Each box represents a single C++ class. Two first classes are the part of PARTONS library, the rest are the part of EpIC project. Classes acting as modules to be used by users are indicated by boldface fonts

3.1 RCModule

Purpose: Simulation of radiative corrections.

Does it depend on the generated process? Yes.

Description: In EpIC, events are generated according to the probability distribution given by:

$$\begin{aligned} \mathrm {d}\sigma (X', Z) = \mathrm {d}\sigma _{0}(X) ~ R(Z)\,. \end{aligned}$$

(1)

Here, $d\sigma _{0}(X)$ is the Born cross-section (given by PARTONS), while R(Z) is the radiator function. The set of variables that the Born cross-section depends on is denoted by X, for instance $X = \{x_{\mathrm {Bj}}, t, Q^2, \phi , \phi _{S}, E_{l} \}$ for DVCS, where $x_{\mathrm {Bj}}$ and $Q^2$ are the usual DIS variables, $\phi$ is the angle between the lepton scattering plane and the production plane, $\phi _{S}$ is the angle between the lepton scattering plane and the target spin component perpendicular to the direction of the virtual photon, and $E_{l}$ is the lepton energy in the fixed target frame, which is the reference frame for the evaluation of cross-section in PARTONS [21]. Because of the radiative corrections, the values of those variables may be different from those for a generated event, $X'$. The radiator function, on the other hand, depends on the set of variables Z. The number of variables making this set depends on the approximation one uses. For instance, if one considers the collinear approximation and only the initial and final state radiations of single photons from the incoming and scattered leptons, two variables make the set Z, namely $Z = \{z_{1}, z_{3}\}$, see Appendix A for more details.

Taking the above into account, modules of type perform three actions: (i) they define a number of variables that the radiative corrections depend on, i.e. they define the set Z, (ii) they implement a function used for the evaluation of R(Z), but also for the evaluation of the “true” kinematics entering the Born cross-section, $X = f(X', Z)$, (iii) they implement a function that stores the four-momenta of radiated photons in the final event records.

3.2 ProcessModule

Purpose: Evaluation of Born cross-section.

Does it depend on the generated process? Yes.

Description: The Born cross-section is evaluated in EpIC using the modules of type, which are defined in the PARTONS library. In the most general case, when the Born cross-section is calculated directly from GPDs, the relies upon other modules: for the evaluation of the process amplitudes, for the evaluation of GPDs at a reference scale, for the evolution of GPDs, for the evaluation of the GPD skewness variable, $\xi$, from the process kinematics, and for the evaluation of the renormalisation and factorisation scales from the process kinematics. However, this general case can hardly be used in the Monte Carlo generation, because of the nested integrations evaluating the Born cross-section. Instead, one may start the evaluation, for instance, from the level of amplitudes parametrised in lookup tables. In this case, and are not used as there is no need for a convolution of GPDs with hard scattering coefficient functions. More details about the modules can be found in Ref. [21].

3.3 EventGeneratorModule

Purpose: Generation of kinematic configurations according to the probability distribution given by the product of the Born cross-section and the radiator function.

Does it depend on the generated process? No.

Description: Modules of this type play a central role in the generation of events. Three actions are implemented in those modules: (i) Initialisation, where the algorithm implemented in the module probes the probability distribution, for instance to “memorise” it using an interpolation method, or to capture its key features, like the location of places in which the probability distribution tends to change rapidly. For some complicated probability distribution functions, the initialisation process can be time-consuming, but the results of the process can be stored in a file for use in subsequent jobs. (ii) Generation of kinematic configurations according to the probability distribution, based on the data collected during the initialisation stage. (iii) Evaluation of the total cross-section, which is needed to normalise the event distributions to a given integrated luminosity.

3.4 KinematicModule

Purpose: Evaluation of four-momenta for a given kinematic configuration.

Does it depend on the generated process? Yes.

Description: Modules of this type are responsible for the evaluation of four-momenta for a given kinematic configuration. In addition, they implement a predefined function that determines if a given kinematic configuration is physical, i.e. if it does not break any kinematic limit. This function is utilised by to probe only valid kinematics.

3.5 WriterModule

Purpose: Composing and saving event records.

Does it depend on the generated process? No.

Description: The purpose of modules of this type is to create and store event records in output files. Different formats may be implemented by different modules. Additional information, like the integrated cross-section, can also be stored in output files, e.g. in their headers.

4 User interface

Both compilation and linking of the project make use of the CMake tool [34]. In the current version (1.0.0) EpIC requires the following external libraries: PARTONS [21] (providing elements of the architecture and used for the evaluation of Born cross-sections), ROOT [35] (used in one of the EventGeneratorModule modules), HepMC3 [36] (used in one of the WriterModule modules), GSL [37] (used for the generation of random numbers). For more detailed and always up-to-date information we refer to the online documentation [24].

The executable of the project, , must be invoked with two arguments, like this:

where SEED is the random seed (unsigned integer) to be used in the initialisation of modules that deal with random numbers, and SCENARIO_PATH is the relative or absolute path to the scenario containing all options used in the generation.

The EpIC scenarios are written in XML markup language which, thanks to the usage of tags based on standard words, is an easy-to-read format for humans while being straightforward for machines to process. EpIC assumes input data to be provided in units of GeV (and its powers, whenever applicable), and radians for angles. The general structure of a single scenario is the following:

Here, we only expose blocks containing specific information, like . Each block is described in one of the subsequent subsections. In our demonstration we only show an exemplary scenario for the DVCS case. More examples, including those for other processes, can be found online [24].

4.1 general_configuration

4.2 kinematic_range

4.3 experimental_conditions

4.4 computation_configuration

4.5 generator_configuration

4.6 kinematic_configuration

4.7 rc_configuration

4.8 writer_configuration

5 EpIC performance

In the following, we demonstrate the detailed performance of EpIC by using specific components of the PARTONS framework. The demonstration is based on one million MC events generated for the DVCS sub-process, i.e. exclusive leptoproduction of a single photon without the Bethe-Heitler contribution, colliding a $10\,\mathrm {GeV}$ positive helicity electron with a $100\,\mathrm {GeV}$ unpolarized proton. The following modules are used during the generation process: DVCSCFFCMILOU3DTables for the parameterisation of the Compton Form Factors (CFFs) obtained from the GK GPD model [31,32,33] and LO coefficient functions, DVCSProcessBMJ12 for the evaluation of the DVCS cross-section based on the set of expressions published in Ref. [39], DVCSRCNull for the simulation without radiative corrections, EventGeneratorFOAM for the generation of DVCS kinematics based on a cross-section with the FOAM algorithm [40], DVCSKinematicDefault for the default evaluation of the four-momenta of the DVCS kinematics, and WriterHepMC3 to save the four-momenta in the HepMC3 format.

The following cuts are used in the generation process: $0.0001\le x_\text {B}\le 0.6$, $0.01\le y\le 0.95$ (here, y is the inelasticity parameter), $1\le Q^2\le 100$ $\text {GeV}^2$, $0\le |t|\le 1$ $\text {GeV}^2$, $0 \le \phi \le 2\pi$, and $0 \le \phi _\text {S} \le 2\pi$. The event distributions based on these cuts are shown in Fig. 4. The following FOAM library parameters are used in producing those events [40]: $\texttt {nCells} = 3000$, $\texttt {nSamples} = 600$, $\texttt {nBins} = 600$. For the FOAM library, the initialisation lasted about 40 minutes, whereas the generation time after initialisation took around 0.0052 seconds per event at the BNL SDCC computer farm. The initialisation time can be shortened by changing the parameters of the FOAM library, which may, however, lead to a longer time to generate a single event. We remind that the result of the initialisation can be stored in a file, allowing one to avoid this step in subsequent MC runs.

To ensure that our results are consistent, we also plot the theory expectation values, as solid lines, on top of each histogram. The number of events associated with the theory curves is calculated as follows: at each bin, the cross-section accounting for the bin width is calculated, and then the result is divided by the total cross-section in the respective phase space. One can then multiply this ratio by the total number of events to find the number of events in that specific bin. To obtain those curves in Fig. 4, we first assign the number of events to the middle point of each bin, and then interpolate between results at these points. As a result, we observe that EpIC generates events in agreement with the theory values.

Fig. 4

Distribution of one million DVCS events produced by the DVCSProcessBMJ12 module utilising GPDGK16 GPDs within the PARTONS framework. Events are binned with respect to $\text {log}_{10}(x_\text {B}), y, Q^2, |t|, \phi$ and $\phi _\text {S}$. The solid curves on top of the histograms depict the expected number of events for the given model. The curves are normalised according to the integrated luminosity estimated by EpIC

6 Summary

In this work, we described in detail the overall structure and essential features of the novel MC generator EpIC. This generator is based on the PARTONS framework in the model selection. It is designed to generate events for exclusive processes, such as DVCS, TCS, DVMP and more broadly for all exclusive processes implemented in the PARTONS framework. As these processes have the potential to reveal the 3D structure of the nucleon through GPDs, they have been studied extensively at facilities such as DESY, JLab, and CERN, and they will remain crucial for future EIC programmes.

The EpIC MC generator stands out with its flexible architecture that utilises a modular programming paradigm. Consequently, the code is easier to understand, as each element of the architecture is designed to perform a specific task. The distribution of events generated by EpIC is highly precise since it utilises an accurate representation of the cross-section of the underlying process in the FOAM library. Besides generating accurate events, EpIC also allows users to generate events integrating radiative corrections as well as to run multi-channel analyses. The comprehensive set of features and the variety of models available in EpIC make it ideal for the systematic study of the 3D structure of the nucleon.

The generator was designed in a way that facilitates easy expansion. The encapsulation of elements is one of the fundamental characteristics of the generator when it comes to maintaining the project for a long time and with a changing team of developers. This allows us to easily adapt the architecture to the latest developments. Finally, to make this project as useful to the particle physics community as possible, we promote open-source standards and offer easy access to its development (EpIC is released through GitHub service [23] under a GPL licence). This perspective is well suited to the experimental timeline of the 3D hadron structure community.

Appendix A: Radiative corrections

Electromagnetic radiative corrections can have a significant impact on the interpretation of experimental data, as they introduce uncertainties in the reconstruction of the “true” kinematics of the measured process. On the other hand, neglecting radiative corrections in simulations typically leads to unrealistic distributions of generated events, resulting in e.g. impact studies that are much less robust. To address both of these problems it is highly desirable to have radiative corrections implemented in MC generators.

In the literature, it has been discussed that the leptonic initial and final state radiative corrections, i.e. when photons are emitted by either incoming or outgoing leptons, respectively, can be computed with a good accuracy in the collinear approximation [41, 42]. In this approximation, the transverse component of the momenta of emitted photons is neglected. Therefore, the radiated photons are restricted to move along the direction of the source leptons.

The collinear approximation allows one to introduce a single parameter, $z_1$ or $z_3$, for the initial or final state radiation, respectively. The parameter describes the energy of the emitted photon:

$$\begin{aligned} z_1 = \frac{E_e - E_\gamma }{E_e}\,, \qquad z_3 = \frac{E_{e^\prime }}{E_{e^\prime } + E_{\gamma ^\prime }} \,, \end{aligned}$$

(A.1)

where $E_{e}$ ( $E_{e^\prime }$) and $E_{\gamma }$ ( $E_{\gamma ^\prime }$) are the energies of the incoming (outgoing) lepton and the initial (final) state emitted photon, respectively. The DIS cross section can be then expressed by [42]:

$$\begin{aligned} \frac{\mathrm {d}^2\sigma }{\mathrm {d}x \, \mathrm {d}y} = \int _{z_1^\text {min}}^1 \frac{\mathrm {d}z_1}{z_1} D(z_1) \int _{z_3^\text {min}}^1 \frac{\mathrm {d}z_3}{z_3^2} {\overline{D}}(z_3)\, \frac{y}{\hat{y}}\, \frac{\mathrm {d}^2{\hat{\sigma }}_{\text {Born}}}{\mathrm {d}{\hat{x}} \, \mathrm {d}{\hat{y}}} \,, \end{aligned}$$

(A.2)

where $\mathrm {d}^2{\hat{\sigma }}_{\text {Born}}$ is the differential Born cross-section evaluated for “true” variables, which are related to the observed ones by [42]:

$$\begin{aligned} {\hat{x}} = \frac{z_1 x y}{z_1 z_3 + y - 1} \,,~ {\hat{y}} = \frac{z_1 z_3 + y - 1}{z_1 z_3} \,, \end{aligned}$$

(A.3)

and where, due to kinematic limits, one has:

$$\begin{aligned} z_1^\text {min} = \frac{1-y}{1-x y}, \qquad z_3^\text {min} = 1-y(1-x)\,. \end{aligned}$$

(A.4)

In Eq. (A.2) the radiator functions, $D(z_{1})$ and ${\overline{D}}(z_3)$, describe the weight of the rescaled cross-section in the presence of the initial and final state radiations, respectively. At the leading order $D(z_1)$ and ${\overline{D}}(z_3)$ are equal to each other and are given by:

$$\begin{aligned} D(z)&= \Bigg [ \delta (1-z)\Bigg [1+\frac{\alpha }{2\pi }L\Bigg (2\ln \,\epsilon + \frac{3}{2}\Bigg )\Bigg ] \nonumber \\&\quad + \theta (1-\epsilon -z)\frac{\alpha }{2\pi }L\frac{1+z^2}{1-z} \Bigg ]\,, \end{aligned}$$

(A.5)

with $L = \ln (Q^2/m_l^2)$. Here, $\alpha$ is the fine-structure constant, and $m_l$ is the lepton mass. The parameter $\epsilon$ acts as a cutoff avoiding the generation of very soft photons characterised by energies $E_\gamma \le \epsilon E_e$ and $E_{\gamma ^\prime } \le \epsilon E_{e^\prime }$. It is crucial to choose the cutoff carefully so that $\epsilon E_e$ and $\epsilon E_{e^\prime }$ are much smaller than the energy resolution of the experiment. Due to the cutoff, Eq. (A.5) consists of two parts: the term proportional to the Dirac delta function collectively describes the contribution of very soft photons and virtual corrections, while the term proportional to the step function describes the effects of real radiation of photons with sizeable energies.

The generalisation of leading order radiative corrections for the DVCS case can be achieved as follows:

$$\begin{aligned} \frac{\mathrm {d}^5\sigma }{\mathrm {d}x \, \mathrm {d}Q^2 \, \mathrm {d}t \, \mathrm {d}\phi \, \mathrm {d}\phi _S}&= \int _{z_1^\text {min}}^1 \mathrm {d}z_1 z_1 D(z_1) \int _{z_3^\text {min}}^1 \frac{\mathrm {d}z_3}{z_3^2} {\overline{D}}(z_3) \nonumber \\&\quad \times \frac{y}{{\hat{y}}}\, \frac{\mathrm {d}^5{\hat{\sigma }}_\text {Born}}{\mathrm {d}{\hat{x}} \, \mathrm {d}{\hat{Q}}^2 \, \mathrm {d}t \, \mathrm {d}\, \phi \, \mathrm {d}\phi _S}\,. \end{aligned}$$

(A.6)