%PARTONS is a software framework dedicated to the phenomenology of 3D hadron structure, in particular Generalized Parton Distributions (GPDs) and Tranverse Momentum Dependent (TMDs) parton distribution functions.
%PARTONS is a C++ software framework dedicated to the phenomenology of Generalized Parton Distributions (GPDs). GPDs provide a comprehensive description of the partonic structure of the nucleon and contain a wealth of new information. In particular, GPDs provide a description of the nucleon as an extended object, referred to as 3-dimensional nucleon tomography, and give an access to the orbital angular momentum of quarks.
%PARTONS provides a necessary bridge between models of 3D hadron structure and experimental data measured in various channels, like for example Deeply Virtual Compton Scattering (DVCS) and Hard Exclusive Meson Production (HEMP).
%PARTONS provides a necessary bridge between models of GPDs and experimental data measured in various exclusive channels, like Deeply Virtual Compton Scattering (DVCS) and Hard Exclusive Meson Production (HEMP). The experimental programme devoted to study GPDs has been carrying out by several experiments, like HERMES at DESY (closed), COMPASS at CERN, Hall-A and CLAS at JLab. GPD subject will be also a key component of the physics case for the expected Electron Ion Collider (EIC).
The experimental program devoted to study GPDs and TMDs has been carrying out by experiments in several facilities, like CERN, DESY, Fermilab, Jefferson Lab and BNL. The 3D structure of hadrons will be also a key component of the physics case for the future Electron Ion Collider (EIC). %PARTONS is useful to theorists to develop new models, phenomenologists to interpret existing measurements and to experimentalists to design new experiments.
%PARTONS is useful to theorists to develop new models, phenomenologists to interpret existing measurements and to experimentalists to design new experiments.
The virtual access infrastructure 3DPartons has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 824093.
# Maximum size of batch for a given type (in one task several batches may be run in separate threads)
gpd.service.batch.size=10000
gpd.service.batch.size=1000
ccf.service.batch.size=1000
observable.service.batch.size=1000
```
The file `xmlSchema.xsd` used by the XML parser is provided both with the library [partons](https://drf-gitlab.cea.fr/partons/core/partons) and the executable project [partons-example](https://drf-gitlab.cea.fr/partons/core/partons-example), in the directory `data`. When `partons` is installed, the file is copied typically to `/usr/local/share/PARTONS`. The same can be said for the `grid` folder containing the PDF replicas.
...
...
@@ -103,11 +105,11 @@ This file contains environment configuration information. The path to this file
@@ -107,12 +109,7 @@ allow to enable the transaction mechanism that is based on temporary files loade
# Database design {#database_design}
The database design reflects the layered structure used in %PARTONS, with tables corresponding to C++ objects and rows corresponding to instances of these objects. There exist also tables storing general information on performed computations. The database design is explained here separately for the common tables and each of the layers by a single UML graph:
*[Database design of tables used by all layers](@ref database_design_1).
*[Database design of GPD layer](@ref database_design_2).
*[Database design of CFF layer](@ref database_design_3).
*[Database design of observable layer](@ref database_design_4).
The database design reflects the layered structure used in %PARTONS, with tables corresponding to C++ objects and rows corresponding to instances of these objects. There exist also tables storing general information on performed computations. The database design is explained in [this graph](@ref database_design_graph).
<hr>
...
...
@@ -129,7 +126,7 @@ This example illustrates how to store a single GPD result into the database via
<scenariodate="2017-01-01"description="Exemplary description - description are very useful!">
@@ -149,50 +146,8 @@ This example illustrates how to store a single GPD result into the database via
</scenario>
```
With the [C++ interface](@ref usage_cpp), users use Services explicitly. Each Service may be seen as a bridge between a single physics-related object and a corresponding SQL table (see [Database design](@ref database_design) section). Services are listed in the following table together with the aforementioned correspondence:
| Service | Corresponding C++ object | Corresponding SQL table name |
For the list of all possible operations provided by Services, see their documentation. Note, that the documentation contains a number of additional examples.
<hr>
# Store experimental data in database {#database_experimentaldata}
The design of the %PARTONS database allows to store experimental data. Not only kinematics and results with uncertainties, but also information concerning related experiments can be stored in the database. These informations can be used later to make systematic comparisons with theoretical predictions, where experimental data are easily selected with a list of user-defined criteria. To introduce a new set of experimental data into the database, one can use scripts provided by our team, to be found in the `data/database/insert_exp_data` folder of your %PARTONS copy. We refer to the file `data/database/insert_experimental_data/README.md` for more information.
Note that, like all resources in the folder `data`, during the installation of %PARTONS, these are copied by default to `/usr/local/share/PARTONS`.
The design of the %PARTONS database allows to store experimental data. Not only kinematics and results with uncertainties, but also information concerning related experiments can be stored in the database. These informations can be used later to make systematic comparisons with theoretical predictions, where experimental data are easily selected with a list of user-defined criteria.
For a detailed description of each virtual function we refer to its documentation, which is available after left-clicking on the function name. A short explanation is also provided by hovering your mouse pointer on the name.
~~~~~~~~~~~~~{.cpp}
class MyCFFModel: public PARTONS::DVCSConvolCoeffFunctionModule {
The implementation of this type of modules is slightly different for \f$\phi\f$-dependent observables (distinguished by PARTONS::ObservableType::PHI) and for those \f$\phi\f$-integrated (distinguished by PARTONS::ObservableType::FOURIER). The good practice is to implement first a given \f$\phi\f$-dependent observable and then as many \f$\phi\f$-integrated derivatives as needed. This is illustrated by the following templates.
We are using the one-observable-is-one-module policy. It means that each module should correspond to only one physics observable. Therefore, such characteristic of observable as beam charge, Fourier modulation type etc. can not be set from the outside (e.g. via `configure()` method), but it must be a genuine property encoded in the module. The policy is in particular crucial for the database integrity, as observable names stored in the database allow to correspond appropriate %PARTONS modules. Therefore, both the names and the modules must be unambiguous.
For a detailed description of each virtual function we refer to its documentation, which is available after left-clicking on the function name. A short explanation is also provided by hovering your mouse pointer on the name.
For a detailed description of each virtual function we refer to its documentation, which is available after left-clicking on the function name. A short explanation is also available after hovering your mouse pointer on the name.
For a detailed description of each virtual function we refer to its documentation, which is available after left-clicking on the function name. A short explanation is also provided by hovering your mouse pointer on the name.
