Changes between Version 67 and Version 68 of HowToAddSample

Timestamp:

Jan 6, 2017, 5:46:48 PM (7 years ago)

Author:

Clarence Wret

Comment:

--

HowToAddSample

@@ -9 +9 @@
 NUISANCE is currently fully written in '''C++03''' and we would appreciate future contributions to adhere to this standard.
 
-'''If you've been using this guide we'd appreciate [mailto:nuisance@projects.hepforge.org feedback].''', thanks.
+'''If you've been using this guide we'd much appreciate [mailto:nuisance@projects.hepforge.org feedback]''', thank you.
 
 {{{
@@ -26 +26 @@
 == Finding the neutrino flux and generating events ==
 
-The first issue at hand is to find the flux for the experiment. If we don't have this, we cant make a generator prediction---unless the measurement is a total cross-section without any phase space cuts (in which case you should probably cast a suspicious eye).
+The first issue at hand is to find the flux for the experiment. If we don't have this, we cant make a generator prediction--unless the measurement is a total cross-section without any phase space cuts (in which case you should probably cast a suspicious eye).
 
 A quick search through the arxiv document points us to reference ![12]. It is also in our [wiki:ExperimentFlux flux list].
 
-I then generate events in NEUT 5.3.6 with a suitable card-file, see our [wiki:HowToNeut NEUT guide] on how to do this. The procedure is very similar for other generators too. '''We need the correct target (water) and flux, and perform the model selections we want (e.g. Rein-Sehgal or Berger-Sehgal coherent model).'''
-
-'''Aim to generate around 1M events with all interaction modes turned on.''' This way we make sure to get all interaction modes into the topologically defined cross-section. We get a small amount of CCQE events which excite a pion from the outgoing nucleon interacting in the nucleus to kick out a pion, leading to a CCQE+1π^+^ ~ CC1π^+^ final state, which is signal for this particular sample.
+I then generate events in NEUT 5.3.6 with a suitable card-file, see our [wiki:HowToNeut NEUT guide] on how to do this. The procedure is very similar for other generators too. We need the '''correct target (water)''' and '''flux''', and perform the '''model selections''' we want (e.g. Rein-Sehgal or Berger-Sehgal coherent model).'''
+
+'''Aim to generate around 1M events with all interaction modes turned on.''' This way we make sure to get all interaction modes into the topologically defined cross-section. We get a small amount of CCQE events which excite a pion from the outgoing nucleon interacting in the nucleus to kick out a pion, leading to a CCQE+1π^+^ ~ CC1π^+^ final state, which is classified signal for this particular sample.
 
 
 == Choosing a cross-section distribution ==
 
-The T2K CC1π^+^ H,,2,,O data release contains various distributions in FIG 4. In this tutorial I'll look at adding one kinematic distribution and one derived distribution: p,,µ,, and E^rec^,,ν,, shown below.
+The T2K CC1π^+^ H,,2,,O data release contains various distributions in FIG 4. In this tutorial I'll look at adding one kinematic distribution and one derived distribution: p,,µ,, and E^rec^,,ν,,, shown below.
 
 [[Image(T2K_CC1pip_H2O_pmu.png​, 300px)]][[Image(T2K_CC1pip_H2O_enurec.png​, 300px)]]
 
-In NUISANCE we try to add all available distributions from a publication. '''However''', some distributions will have detector effects "folded" into them (i.e. they will be raw detector-level data). We can only use these if there is some method which bring detector-level variables (e.g. p,,µ,, seen in the detector) to truth-level variable (e.g. p,,µ,, seen after correcting for the detector effects).
+In NUISANCE we try to add all available distributions from a publication. '''However''', some distributions will have '''detector effects''' "folded" into them (i.e. they will be raw detector-level data). We can only use these if there is some method which bring detector-level variables (e.g. p,,µ,, seen in the detector) to truth-level variable (e.g. p,,µ,, seen after correcting for the detector effects).
 
 
@@ -51 +51 @@
 Each experimental measurement is its own class. To simplify including new samples we supply a base class for 1D (`Measurement1D`) and 2D (`Measurement2D`) measurements, which in turn inherits from the virtual base class (`MeasurementBase`).
 
-These `MeasurementBase` classes are then looped over in the executables and data/MC comparisons are the result. A class has to at least inherit from `MeasurementBase` and implement the necessary methods to be "looped over". The recommended method is to use and expand the supplied `Measurement1D` and `Measurement2D` classes; anything else may require expert knowledge and won't be covered here. 
+These `MeasurementBase` classes are looped over from the executables and data/MC comparisons are the result, calling functions like `MeasurementBase::Reconfigure`, `MeasurementBase::FillEventVariables`, `MeasurementBase::isSignal` and `MeasurementBase::GetLikelihood`. 
+
+A class has to at least inherit from `MeasurementBase` and implement the necessary methods to be "looped over". The recommended method is to use and expand the supplied `Measurement1D` and `Measurement2D` classes; anything else may require expert knowledge and won't be covered here.
 
 The inheritance tree is simple and goes `Specific_Measurement -> MeasurementXD -> MeasurementBase`
+
 
 [=#point_naming]
 == Naming the sample ==
 
-Some automatic processing is done on loading up the samples to set up generator scaling factors, chi2 calculations and so on. These are simple string comparisons done in the base class constructors, but do '''place responsibility on the user'''.
+Some automatic processing is done on loading up the samples to set up generator scaling factors, χ^2^ calculations and so on. These are simple string comparisons done in the base class constructors, but do '''place responsibility on the user'''.
 
 
@@ -75 +78 @@
 '''What to do:'''
 
-Following the above convention, we end up with '''`T2K_CC1pip_H2O_XSec_1Dpmu_nu`''': there is no ambiguity what the class describes and there is no way of confusing it with other classes in NUISANCE.
+Following the above convention, we end up with '''`T2K_CC1pip_H2O_XSec_1Dpmu_nu`'''.
+
+This is a sufficient name: there is no ambiguity what the class describes and there is no way of confusing it with other classes in NUISANCE.
 
 
@@ -100 +105 @@
 Furthermore, we specify another directory for the measurement topology to avoid confusion, e.g. `data/T2K/CC1pip` for our sample.
 
-In some cases we might have the same topology defining the cross-section but for different targets. In this case we add another sub-directory for the target, e.g. `data/T2K/CC1pip/H2O`.
+In some cases we might have the same topology defining the cross-section but for a different interaction target. In this case we add another sub-directory for the target, e.g. `data/T2K/CC1pip/H2O` for us.
 
 
@@ -110 +115 @@
 {{{
 #!html
-<hr width="100%" size="4">
+<hr width="100%" size="10">
 }}}
 = Coding up a sample =
 
-Now that we have the rough structure set-up, we can finally start writing some code.
+Now that we have the rough structure set-up, we can start writing some code.
 
 [=#point_header]
 == Writing the header ==
 
-In the case of our T2K CC1π^+^ H,,2,,O data, we're dealing with 1D distributions. They should therefore inherit from the `Measurement1D` base class, as mentioned [#point_base earlier]. The `Measurement1D` class is implemented in `src/FitBase/Measurement1D.cxx`.
-
-NUISANCE requires a `constructor` and `destructor` for the class, and we'll need to overload `MeasurementBase` methods which define the dependent variable(s) (p,,µ,, in our case) and what our signal is (CC interaction with one muon and one positive pion with no other pions or mesons and any number of nucleons in our case). The `MeasurementBase` functions which we need to overload are `MeasurementBase::isSignal(FitEvent *event)` and `MeasurementBase::FillEventVariables(FitEvent *event)`. 
-
-The `FitEvent` class is an object which contains information about one single event: all the particles, their kinematics and their status after the interaction, the interaction channel which produced the final state, possible secondary interactions, the interaction target, and so on.  The `FitEvent` class is implemented in `src/FitBase/FitEvent.cxx` and essentially the generator-independent common event format which NUISANCE uses for the generator events.
+The T2K CC1π^+^ H,,2,,O data is all 1D distributions. The new classes should therefore inherit from the `Measurement1D` base class, as mentioned [#point_base earlier]. The `Measurement1D` class is implemented in `src/FitBase/Measurement1D.cxx`.
+
+NUISANCE requires a `constructor` and `destructor` for the class, and we'll need to overload `MeasurementBase` methods which define the dependent variable(s) (p,,µ,, and E^rec^,,ν,, in our case) and what our signal is (CC interaction with one muon and one positive pion with no other pions or mesons and any number of nucleons in our case). The `MeasurementBase` functions which we need to overload are `MeasurementBase::isSignal(FitEvent *event)` and `MeasurementBase::FillEventVariables(FitEvent *event)`. 
+
+The `FitEvent` class is an object which contains information about one single event: all the particles, their kinematics and their status before and after the interaction, the interaction channel(s) which produced the final state particles, possible secondary interactions, the interaction target, and so on.  The `FitEvent` class is implemented in `src/FitBase/FitEvent.cxx` and is the generator-independent "common event format" which NUISANCE uses for the generator events.
 
 [=#point_signal]