Commit 433040ba authored by Pawel Sznajder's avatar Pawel Sznajder
Browse files

update web page

parent 7d5c49d5
# Main Page {#mainpage}
[TOC]
# What is PARTONS? {#mainpage_intro}
<img src='../images/logo_partons.jpg' alt='PARTONS' style='float:right; max-width:20%; height:auto; margin:2pt 10pt' />
<img src='../images/logo_partons_strong.png' alt='PARTONS' style='float:right; max-width:17%; height:auto; margin:2pt 10pt' />
%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.
<hr>
......
......@@ -39,6 +39,7 @@ xml.schema.file.path = ../partons/data/xmlSchema.xsd
# Database connection definition (for more information see our tutorial explaining the database usage)
database.production.type = MYSQL
database.production.url = localhost
database.production.port = 3306
database.production.dbname = partons
database.production.user = partons
database.production.passwd = partons
......@@ -55,8 +56,9 @@ database.load.infile.directory = /path/to/tmp
computation.nb.processor = 1
# 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
```
system: Linux partonsVM 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64 GNU/Linux
g++: 4.9.2
root: 5.34/19
qt: 4.8.6
smfl: 2.1
eigen3: 3.2.2
cln: 1.3.4
gsl: 2.3
git elementary-utils: master/2e0e9ee721aa46262545fa9963e935073f829e3e
git numa: master/c13779a34c4847b67cf2f55d12c58fde8c78696b
git partons: master/72bdcfc08c6dd7d8ec8386dc0d36449b4fd28fad
......@@ -137,11 +139,11 @@ GIT_PARTONS="`git branch | grep \* | sed -e 's/\* '//g`/`git rev-parse HEAD`"
echo "system: `uname -a`"
echo "g++: `g++ -dumpversion`"
echo "root: `root-config --version`"
echo "qt: `pkg-config --modversion QtCore`"
echo "smfl: $SFML_A.$SFML_B"
echo "eigen3: `pkg-config --modversion eigen3`"
echo "cln: `pkg-config --modversion cln`"
echo "gsl: `gsl-config --version`"
echo "git elementary-utils: $GIT_ELEM_UTILS"
echo "git numa: $GIT_NUMA"
echo "git partons: $GIT_PARTONS"
......
# Contact {#contact}
# Contact and support {#contact}
Main contact: [partons@cea.fr](mailto:partons@cea.fr).
<hr>
# Technical support {#contact_support}
Problems with installation and usage: [partons@cea.fr](mailto:partons@cea.fr).
Use this e-mail adress: [partons@cea.fr](mailto:partons@cea.fr). You may also find us on [riot.im](https://riot.im/app/#/group/+partons:matrix.org).
<hr>
......
......@@ -82,6 +82,7 @@ Connection to a local server:
```py
database.production.type = MYSQL
database.production.url = localhost
database.production.port = 3306
database.production.dbname = your_partons_database_name
database.production.user = your_sql_user_name
database.production.passwd = your_sql_user_password
......@@ -91,6 +92,7 @@ Connection to a remote server:
```py
database.production.type = MYSQL
database.production.url = remote.address.example.com
database.production.port = 3306
database.production.dbname = your_partons_database_name
database.production.user = your_sql_user_name
database.production.passwd = your_sql_user_password
......@@ -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
<scenario date="2017-01-01" description="Exemplary description - description are very useful!">
<task service="GPDService" method="computeGPDModel" storeInDB="1">
<task service="GPDService" method="computeSingleKinematic" storeInDB="1">
<kinematics type="GPDKinematic">
<param name="x" value="-0.1" />
<param name="xi" value="0.05" />
......@@ -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 |
| :---- | :---- | :---- |
| [GPDKinematicDaoService](@ref PARTONS::GPDKinematicDaoService) | [GPDKinematic](@ref PARTONS::GPDKinematic) | [gpd_kinematic](@ref database_design_2) |
| [GPDResultDaoService](@ref PARTONS::GPDResultDaoService) | [GPDResult](@ref PARTONS::GPDResult) | [gpd_result](@ref database_design_2) |
||||
| [ConvolCoeffFunctionKinematicDaoService](@ref PARTONS::ConvolCoeffFunctionKinematicDaoService) | [DVCSConvolCoeffFunctionKinematic](@ref PARTONS::DVCSConvolCoeffFunctionKinematic) | [cff_kinematic](@ref database_design_3) |
| [ConvolCoeffFunctionResultDaoService](@ref PARTONS::ConvolCoeffFunctionResultDaoService) | [DVCSConvolCoeffFunctionResult](@ref PARTONS::DVCSConvolCoeffFunctionResult) | [cff_result](@ref database_design_3) |
||||
| [ObservableKinematicDaoService](@ref PARTONS::ObservableKinematicDaoService) | [ObservableKinematic](@ref PARTONS::ObservableKinematic) | [observable_kinematic](@ref database_design_4) |
| [ObservableResultDaoService](@ref PARTONS::ObservableResultDaoService) | [ObservableResult](@ref PARTONS::ObservableResult) | [observable_result](@ref database_design_4) |
This example illustrates how to use Services via C++ interface:
```cpp
//evaluate exemplary GPD result to be inserted in database
//retrieve GPD service
PARTONS::GPDService* pGPDService = PARTONS::Partons::getInstance()->getServiceObjectRegistry()->getGPDService();
//load GPD module with the BaseModuleFactory
PARTONS::GPDModule* pGPDModel = PARTONS::Partons::getInstance()->getModuleObjectFactory()->newGPDModule(PARTONS::GPDMMS13::classId);
//define GPD kinematics used in computation
PARTONS::GPDKinematic gpdKinematic(-0.1, 0.05, 0., 2., 2.);
//define list of GPD types to be computed
PARTONS::List<GPDType> gpdTypeList;
gpdTypeList.add(PARTONS::GPDType::ALL);
//evaluate
PARTONS::GPDResult gpdResult = pGPDService->computeGPDModel(gpdKinematic, pGPDModel, gpdTypeList);
//get GPDResultDaoService
PARTONS::GPDResultDaoService gpdResultDaoService;
//insert result into database
int id = gpdResultDaoService.insert(gpdResult);
```
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.
# Database design # {#database_design_graph}
![Database design](../images/database_design_common.png "Database design of tables used by all layers")
# Database design - tables used by all layers # {#database_design_1}
![Database design of tables used by all layers](../images/database_design_common.png "Database design of tables used by all layers")
# Database design - GPD layer # {#database_design_2}
![Database design of gpd layer](../images/database_design_gpd.png "Database design of gpd layer")
# Database design - CFF layer # {#database_design_3}
![Database design of cff layer](../images/database_design_cff.png "Database design of cff layer")
# Database design - observable layer # {#database_design_4}
![Database design of observable layer](../images/database_design_observable.png "Database design of observable layer")
......@@ -13,10 +13,10 @@ The sources are accessible:
* via the Git command line tool:
~~~~~~~~~~~~~{.sh}
cd /path/to/some/directory
GIT_SSL_NO_VERIFY=true git clone https://drf-gitlab.cea.fr/partons/core/elementary-utils.git --branch v1.0 --depth 1
GIT_SSL_NO_VERIFY=true git clone https://drf-gitlab.cea.fr/partons/core/numa.git --branch v1.0 --depth 1
GIT_SSL_NO_VERIFY=true git clone https://drf-gitlab.cea.fr/partons/core/partons.git --branch v1.0 --depth 1
GIT_SSL_NO_VERIFY=true git clone https://drf-gitlab.cea.fr/partons/core/partons-example.git --branch v1.0 --depth 1
GIT_SSL_NO_VERIFY=true git clone https://drf-gitlab.cea.fr/partons/core/elementary-utils.git --branch v2.0 --depth 1
GIT_SSL_NO_VERIFY=true git clone https://drf-gitlab.cea.fr/partons/core/numa.git --branch v2.0 --depth 1
GIT_SSL_NO_VERIFY=true git clone https://drf-gitlab.cea.fr/partons/core/partons.git --branch v2.0 --depth 1
GIT_SSL_NO_VERIFY=true git clone https://drf-gitlab.cea.fr/partons/core/partons-example.git --branch v2.0 --depth 1
~~~~~~~~~~~~~
The option `--branch` is needed to checkout the specific tagged version from the *release* branch.
The option `GIT_SSL_NO_VERIFY=true` is needed because the CEA certificate is often not recognized.
......@@ -24,8 +24,8 @@ The option `--depth 1` can be used to download only the tagged commit and nothin
* via the following links:
Version | Status | elementary-utils | numa | partons | partons-example |
:------: | :----------------------------------------------: | :-------------------------: | :-------------------------: | :---------------------------: | :---------------------------: |
1.0 | <pre style="color: green;">Latest version</pre> | [tar.gz](https://drf-gitlab.cea.fr/partons/core/elementary-utils/repository/v1.0/archive.tar.gz) | [tar.gz](https://drf-gitlab.cea.fr/partons/core/numa/repository/v1.0/archive.tar.gz) | [tar.gz](https://drf-gitlab.cea.fr/partons/core/partons/repository/v1.0/archive.tar.gz) | [tar.gz](https://drf-gitlab.cea.fr/partons/core/partons-example/repository/v1.0/archive.tar.gz) |
2.0 | <pre style="color: green;">Latest version</pre> | [tar.gz](https://drf-gitlab.cea.fr/partons/core/elementary-utils/repository/v2.0/archive.tar.gz) | [tar.gz](https://drf-gitlab.cea.fr/partons/core/numa/repository/v2.0/archive.tar.gz) | [tar.gz](https://drf-gitlab.cea.fr/partons/core/partons/repository/v2.0/archive.tar.gz) | [tar.gz](https://drf-gitlab.cea.fr/partons/core/partons-example/repository/v2.0/archive.tar.gz) |
1.0 | <pre style="color: red;">Old</pre> | [tar.gz](https://drf-gitlab.cea.fr/partons/core/elementary-utils/repository/v1.0/archive.tar.gz) | [tar.gz](https://drf-gitlab.cea.fr/partons/core/numa/repository/v1.0/archive.tar.gz) | [tar.gz](https://drf-gitlab.cea.fr/partons/core/partons/repository/v1.0/archive.tar.gz) | [tar.gz](https://drf-gitlab.cea.fr/partons/core/partons-example/repository/v1.0/archive.tar.gz) |
<hr>
......
......@@ -105,9 +105,6 @@ double integrationResult = integrate(m_pFunctorForIntegrationFunction, min, max,
# Templates for new modules {#newmodule_templates}
* [New GPD module](@ref newmodule_templates_gpd)
* [New DVCS CFF module](@ref newmodule_templates_dvcscff)
* [New DVCS process module](@ref newmodule_templates_dvcsprocess)
* [New DVCS observable](@ref newmodule_templates_dvcsobservable)
<hr>
......
# New DVCS CFF module {#newmodule_templates_dvcscff}
[TOC]
# Header file template {#newmodule_templates_dvcscff_h}
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 {
public:
/*/** */*
* ID assigned by BaseObjectRegistry.
*/
static const unsigned int classId;
/*/** */*
* Default constructor.
* @param className Name of class.
*/
MyCFFModel(const std::string &className);
/*/** */*
* Destructor.
*/
virtual ~MyCFFModel();
virtual MyCFFModel* clone() const;
virtual void resolveObjectDependencies();
virtual void configure(const ElemUtils::Parameters &parameters);
protected:
/*/** */*
* Copy constructor.
* @param other Object to be copied.
*/
MyCFFModel(const MyCFFModel &other);
virtual void isModuleWellConfigured();
virtual void initModule();
virtual std::complex<double> computeUnpolarized();
virtual std::complex<double> computePolarized();
};
~~~~~~~~~~~~~
# Source code file template {#newmodule_templates_dvcscff_cpp}
~~~~~~~~~~~~~{.cpp}
const unsigned int MyCFFModel::classId =
PARTONS::BaseObjectRegistry::getInstance()->registerBaseObject(new MyCFFModel("MyCFFModel"));
MyCFFModel::MyCFFModel(const std::string& className) :
PARTONS::DVCSConvolCoeffFunctionModule(className) {
//relate a specific GPD type with the appropriate function
m_listOfCFFComputeFunctionAvailable.insert(
std::make_pair(PARTONS::GPDType::H,
&PARTONS::DVCSConvolCoeffFunctionModule::computeUnpolarized));
m_listOfCFFComputeFunctionAvailable.insert(
std::make_pair(PARTONS::GPDType::E,
&PARTONS::DVCSConvolCoeffFunctionModule::computeUnpolarized));
m_listOfCFFComputeFunctionAvailable.insert(
std::make_pair(PARTONS::GPDType::Ht,
&PARTONS::DVCSConvolCoeffFunctionModule::computePolarized));
m_listOfCFFComputeFunctionAvailable.insert(
std::make_pair(PARTONS::GPDType::Et,
&PARTONS::DVCSConvolCoeffFunctionModule::computePolarized));
//this can be used to indicate that this CFF module does not need GPD module
//default is that GPD module is needed, so the below line can be omitted
setIsGPDModuleDependent(true);
}
MyCFFModel::MyCFFModel(const MyCFFModel& other) : PARTONS::DVCSConvolCoeffFunctionModule(other) {
}
MyCFFModel::~MyCFFModel() {
}
MyCFFModel* MyCFFModel::clone() const {
return new MyCFFModel(*this);
}
void MyCFFModel::resolveObjectDependencies() {
PARTONS::DVCSConvolCoeffFunctionModule::resolveObjectDependencies();
}
void MyCFFModel::configure(const ElemUtils::Parameters &parameters) {
PARTONS::DVCSConvolCoeffFunctionModule::configure(parameters);
}
void MyCFFModel::isModuleWellConfigured() {
PARTONS::DVCSConvolCoeffFunctionModule::isModuleWellConfigured();
}
void MyCFFModel::initModule() {
PARTONS::DVCSConvolCoeffFunctionModule::initModule();
}
std::complex<double> MyCFFModel::computeUnpolarized() {
//result
std::complex<double> result;
//your implementation comes here
//return
return result;
}
std::complex<double> MyCFFModel::computePolarized() {
//see MyCFFModel::computeUnpolarized()
}
~~~~~~~~~~~~~
# Useful variables {#newmodule_templates_dvcscff_var}
These are the most useful variables defined in the abstract classes. They are crucial for the implementation of new CFF modules.
* PARTONS::DVCSConvolCoeffFunctionModule::m_xi, PARTONS::DVCSConvolCoeffFunctionModule::m_t, PARTONS::DVCSConvolCoeffFunctionModule::m_MuF2, PARTONS::DVCSConvolCoeffFunctionModule::m_MuR2: indicate CFF kinematics being evaluated
* PARTONS::DVCSConvolCoeffFunctionModule::m_currentGPDComputeType: indicate GPD type being evaluated
* PARTONS::DVCSConvolCoeffFunctionModule::m_qcdOrderType: indicate pQCD order being evaluated
* PARTONS::ConvolCoeffFunctionModule::m_pGPDModule: pointer to GPD module being used
# New DVCS observable module {#newmodule_templates_dvcsobservable}
[TOC]
# Introduction {#newmodule_templates_dvcsobservable_intro}
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.
<hr>
# Header file template (phi-dependent observable) {#newmodule_templates_dvcsobservable_hdep}
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 MyObservable: public PARTONS::Observable {
public:
/*/** */*
* ID assigned by BaseObjectRegistry.
*/
static const unsigned int classId;
/*/** */*
* Default constructor.
* @param className Name of class.
*/
MyObservable(const std::string &className);
/*/** */*
* Destructor.
*/
virtual ~MyObservable();
virtual MyObservable* clone() const;
virtual double computePhiObservable(double phi);
protected:
/*/** */*
* Copy constructor.
* @param other Object to be copied.
*/
MyObservable(const MyObservable &other);
};
```
# Source code file template (phi-dependent observable) {#newmodule_templates_dvcsobservable_cppdep}
```cpp
const unsigned int MyObservable::classId =
PARTONS::BaseObjectRegistry::getInstance()->registerBaseObject(new MyObservable("MyObservable"));
MyObservable::MyObservable(const std::string &className) :
PARTONS::Observable(className) {
m_observableType = PARTONS::ObservableType::PHI;
m_channel = PARTONS::ObservableChannel::DVCS;
}
MyObservable::MyObservable(const MyObservable& other) :
PARTONS::Observable(other) {
}
MyObservable::~MyObservable() {
}
MyObservable* MyObservable::clone() const {
return new MyObservable(*this);
}
double MyObservable::computePhiObservable(double phi) {
//result
double result;
//your implementation comes here
...
//return
return result;
}
```
# Header file template (phi-integrated observable) {#newmodule_templates_dvcsobservable_hindep}
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.
```cpp
class MyObservableFourierModulation: public MyObservable, public PARTONS::MathIntegratorModule {
public:
/*/** */*
* ID assigned by BaseObjectRegistry.
*/
static const unsigned int classId;
/*/** */*
* Default constructor.
* @param className Name of class.
*/
MyObservableFourierModulation(const std::string &className);
/*/** */*
* Destructor.
*/
virtual ~MyObservableFourierModulation();
virtual MyObservableFourierModulation* clone() const;
virtual double computeFourierObservable();
protected:
/*/** */*
* Copy constructor.
* @param other Object to be copied.
*/
MyObservableFourierModulation(const MyObservableFourierModulation &other);
/*/** */*
* Functor pointing to MyObservableFourierModulation::functionToIntegrateObservable().
*/
NumA::FunctionType1D* m_pFunctionToIntegrateObservable;
/*/** */*
* Function to integrate over phi angle.
*/
virtual double functionToIntegrateObservable(double x,
std::vector<double> params);
/*/** */*
* Initialize functors.
*/
void initFunctorsForIntegrations();
};
```
# Source code file template (phi-integrated observable) {#newmodule_templates_dvcsobservable_cppindep}
```cpp
const unsigned int MyObservableFourierModulation::classId =
PARTONS::BaseObjectRegistry::getInstance()->registerBaseObject(new MyObservableFourierModulation("MyObservableFourierModulation"));
MyObservableFourierModulation::MyObservableFourierModulation(const std::string &className) :
MyObservable(className), PARTONS::MathIntegratorModule() {
m_observableType = PARTONS::ObservableType::FOURIER;
m_channel = PARTONS::ObservableChannel::DVCS;
setIntegrator(NumA::IntegratorType1D::DEXP);
initFunctorsForIntegrations();
}
MyObservableFourierModulation::MyObservableFourierModulation(const MyObservableFourierModulation& other) :
MyObservable(other), PARTONS::MathIntegratorModule(other) {
initFunctorsForIntegrations();
}
MyObservableFourierModulation::~MyObservableFourierModulation() {
if (m_pFunctionToIntegrateObservable) {
delete m_pFunctionToIntegrateObservable;
m_pFunctionToIntegrateObservable = 0;
}
}
MyObservableFourierModulation* MyObservableFourierModulation::clone() const {
return new MyObservableFourierModulation(*this);
}
void MyObservableFourierModulation::initFunctorsForIntegrations() {
m_pFunctionToIntegrateObservable =
NumA::Integrator1D::newIntegrationFunctor(this,
&MyObservableFourierModulation::functionToIntegrateObservable);
}
double MyObservableFourierModulation::functionToIntegrateObservable(double x,
std::vector<double> params) {
//your implementation comes here, e.g.:
return MyObservable::computePhiObservable(x) * cos(x);
}
double MyObservableFourierModulation::computeFourierObservable() {
//your implementation comes here, e.g.:
std::vector<double> emptyParameters;
return integrate(m_pFunctionToIntegrateObservable, 0., (2 * PARTONS::Constant::PI),
emptyParameters) / PARTONS::Constant::PI;
}
```
# Useful variables {#newmodule_templates_dvcsobservable_var}
These are the most useful variables defined in the abstract classes. They are crucial for the implementation of new observable modules.
* PARTONS::Observable::m_pProcessModule: pointer to observable process being used
# New DVCS process module {#newmodule_templates_dvcsprocess}
[TOC]
# Header file template {#newmodule_templates_dvcsprocess_h}
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 MyDVCSProcess: public PARTONS::DVCSModule {
public:
/*/** */*
* ID assigned by BaseObjectRegistry.
*/
static const unsigned int classId;
/*/** */*
* Default constructor.
* @param className Name of class.
*/
MyDVCSProcess(const std::string &className);
/*/** */*
* Destructor.
*/
virtual ~MyCFFModel();
virtual ~MyDVCSProcess();
virtual MyDVCSProcess* clone() const;
virtual void resolveObjectDependencies();
virtual void configure(const ElemUtils::Parameters &parameters);
protected:
/*/** */*
* Copy constructor.
* @param other Object to be copied.
*/
MyDVCSProcess(const MyDVCSProcess& other);
virtual void initModule();
virtual void initModule(double beamHelicity, double beamCharge,
NumA::Vector3D targetPolarization);
virtual void isModuleWellConfigured();