Changes between Version 68 and Version 69 of HowToAddSample

Timestamp:

Jan 6, 2017, 11:16:07 PM (7 years ago)

Author:

Clarence Wret

Comment:

--

HowToAddSample

@@ -3 +3 @@
 This is an informal step-by-step guide on how to add samples into the NUISANCE framework. Most of this can be derived by looking at the recently [https://nuisance.hepforge.org/trac/browser/src?order=date&desc=1 implemented measurements] for up-to-date references.
 
-For this tutorial I'll be adding the '''T2K CC1π^+^ H,,2,,O data'''. The data comes from the [http://t2k-experiment.org/results/nd280data-numu-cc1pi-xs-on-h2o-2015/ T2K site] and [https://arxiv.org/abs/1605.07964 arxiv]. The data is supplied [http://t2k-experiment.org/wp-content/uploads/nd280data-numu-cc1pi-xs-on-h2o-2015.tar both in a ROOT file and a number of .csv files]: I'll be using the ROOT file here but very similar steps apply when using .csv or .txt. files.
+For this tutorial I'll be adding the '''T2K CC1π^+^ H,,2,,O data'''. The data comes from the [http://t2k-experiment.org/results/nd280data-numu-cc1pi-xs-on-h2o-2015/ T2K site] and [https://arxiv.org/abs/1605.07964 arxiv]. The data is supplied [http://t2k-experiment.org/wp-content/uploads/nd280data-numu-cc1pi-xs-on-h2o-2015.tar both in a ROOT file and a number of .csv files]: I'll be using the ROOT file here but very similar steps apply when using .csv or .txt files.
 
 After implementing we'll be able to make data/MC comparisons to the T2K CC1π^+^ H,,2,,O data for NEUT, GENIE, GiBUU and !NuWro, all in the same framework. We'll get MC predictions, χ^2^ values, interaction mode contributions, and more using a consistent signal definition, guaranteed the same across the generators.
@@ -78 +78 @@
 '''What to do:'''
 
-Following the above convention, we end up with '''`T2K_CC1pip_H2O_XSec_1Dpmu_nu`'''.
+Following the above convention, we end up with '''`T2K_CC1pip_H2O_XSec_1Dpmu_nu`''' and '''`T2K_CC1pip_H2O_XSec_1DEnuMB_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.
@@ -94 +94 @@
 '''What to do:'''
 
-Make the new files '''`src/T2K/T2K_CC1pip_H2O_XSec_1Dpmu_nu.cxx`''' and '''`src/T2K/T2K_CC1pip_H2O_1Dpmu_nu.h`'''. These are the implementation and header files for the new measurement.
+Make the new files '''`src/T2K/T2K_CC1pip_H2O_XSec_1Dpmu_nu.cxx`''' and '''`src/T2K/T2K_CC1pip_H2O_1Dpmu_nu.h`'''. These are the implementation and header files for the new measurement and similar goes for the `1DEnuMB` implementation.
 
 
@@ -124 +124 @@
 == Writing the header ==
 
-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`.
+The T2K CC1π^+^ H,,2,,O data are 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)`. 
@@ -131 +131 @@
 
 [=#point_signal]
-We see that the `src/T2K` directory contains `T2K_SignalDef.cxx`. This extends the `SignalDef` namespace which holds many of the signal definitions for the classes. If you're implementing multiple distributions for the same measurement (e.g. dSig/dp,,µ,, and dSig/dcosθ,,µ,,) we recommend adding the signal definition to the namespace rather than directly in the `isSignal(FitEvent *event)` function in the class implementation. We'll talk about implementing a signal definition [#point_signaldef later].
+We also note that the `src/T2K` directory contains `T2K_SignalDef.cxx`. This extends the `SignalDef` namespace which holds many of the signal definitions for the classes. `SignalDef` itself lives in `src/Utils/SignalDef.cxx`, but may see additions from experiment folders such as `src/T2K/T2K_SignalDef.cxx`.
+
+If you're implementing multiple distributions for the same measurement (e.g. dσ/dp,,µ,, and dσ/dcosθ,,µ,,) we recommend adding the signal definition to the namespace rather than directly in the `isSignal(FitEvent *event)` function in the class implementation. We'll talk about implementing a signal definition [#point_signaldef later].
 
 
@@ -160 +162 @@
 where we've copied the constructor arguments from some other class we're using as a template. I'll elaborate more on this [#point_const below].
 
+Note the simple structure for the sample: we really only need to set up three functions. The inheritance from `Measurement1D` and helper function within it does most of the heavy lifting.
+
 
 [=#point_const]
 == Writing the constructor ==
 
-NUISANCE loads samples through `FCN/SampleList.cxx` in the function `SampleUtils::LoadSample`, which makes a `std::list` of `MeasurementBase` pointers which it later loops over from the executables.
+NUISANCE loads samples through `FCN/SampleList.cxx` in the function `SampleUtils::LoadSample`. This function makes a `std::list` of `MeasurementBase` pointers which it later loops over in calls from the executables.
 
 Most of the automated setting up of histograms, titles, and so on is done in `Measurement1D::SetupMeasurement(std::string inputfile, std::string type, FitWeight *rw, std::string fakeDataFile)`. It hence makes sense to have a class constructor which passes all of these on to `SetupMeasurement`.
@@ -225 +229 @@
 The data and covariance matrix are available in a ROOT file for the sample, so I used `Measurement1D::SetDataFromFile` to set up the data and `Measurement1D::SetCovarFromDataFile` to set up the covariances.
 
-`fName` and the other `std::string`s were set to reasonable names and `fScaleFactor` was 
+`fName` and the other `std::string`s were set to reasonable names and `fScaleFactor` was set to the default mentioned above.
 
 The `constructor` for the class now looks like:
@@ -263 +267 @@
 We are now at the point where we can write the `FillEventVariables(FitEvent *event)` implementation mentioned [=#point_header above]. This function defines the dependent variable(s) and how to get them from each `FitEvent` object that gets passed.
 
-This is where the p,,μ,, and E^rec^,,ν,, implementations differ.
-
-The `FitEvent` class provides numerous getter functions to make `FillEventVariables` as simple as possible.
+The `FitEvent` class provides numerous getter functions to make `FillEventVariables` implementation as simple as possible.
+
+This is the only major point where the p,,μ,, and E^rec^,,ν,, implementations differ.
 
 [=#point_muon_dist]
@@ -337 +341 @@
 }}}
 
-We should now write a helper function in the `FitUtils` namespace to get `E^rec^,,ν,,` from the muon, pion and neutrino `TLorentzVector`s. [https://arxiv.org/pdf/1605.07964v2.pdf The paper] specifies the exact form in equation 1. The `FitUtils` implementation lives in `src/Utils/FitUtils.cxx`.
+We should now write a helper function in the `FitUtils` namespace to get E^rec^,,ν,, from the muon, pion and neutrino `TLorentzVector`s. [https://arxiv.org/pdf/1605.07964v2.pdf The paper] specifies the exact form in equation 1. The `FitUtils` implementation lives in `src/Utils/FitUtils.cxx`.
 
 {{{