MONA - Mass Ordering Nikhef Analysis
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Pages
Main page

What is MONA?

MONA stands for "Mass Ordering Nikhef Analysis" and is a software package that provides some tools for estimating the ORCA sensitivity to neutrino mass ordering. Other ORCA analyses can also be accommodated. It relies on Monte-Carlo data from ORCA simulation chain (discussed separately in section ORCA Monte-Carlo chain and data format). Broadly put, it provides tools to filter experiment data (either simulated or sea-data) and create detector responses to fit the filtered experiment data with RooFit.

Directory structure

Prerequisities

Documentation

Versioning

The numbers in the version string vA.B.C-D, where A to D are numbers, have the following meaning:

Setup in lyon and elsewhere

Setup for usage

This really depends on what is the targeted use of the software. For example, for the calculation of the atmosperic neutrino flux, the class common_software/AtmFlux.h/C can be used on the root prompt after compilation and nothing else is required. However, for something more advanced that requires ORCA MC data, the following tasks are usually required.

1. Data format conversion

When Monte-Carlo data is in the equation, it needs to be in the analysis format, defined by common_software/SummaryEvent.h/C (reasons for this are discussed in detail in section ORCA Monte-Carlo chain and data format below). For example, consider ORCA MC summary file from ECAP from April 18 /sps/km3net/users/shallman/ORCA_PID_OUTPUT/04_18/pid_result_shiftedVertexEventSelection.root. The applications in apps/data_sorting/ can be used to perform the conversion, see apps/data_sorting/README.md for more info.

2. Effective mass

Effective mass is required to predict the number of selected neutrino events in the detector in some time period. Typically, selected is defined as the events that would pass the trigger and simple atmospheric muon rejection cuts and end up in the ECAP PID output tree. The class common_software/EffMass.h/C provides a class that performs effective mass calculations, given an input file with histograms for selected (ECAP PID events) and generated (gSeaGen) events. The applications in apps/effective_mass can be used to create such a file, see apps/effective_mass/README.md for more info.

3. Bjorken-y distributions

To distribute expectation values for selected events in bjorken-y (in addition to the conventional energy and cos-theta), knowledge of a 2D neutrino energy vs bjorken-y distribution is required. Such distributions can be generated from gSeaGen data, the applications in apps/bjorkeny_dists create such distributions, see apps/bjorkeny_dists/README.md for more info. Note that one such distribution file was generated from gSeaGen v4r1 data and comes with the repo. If significant updates are expected to the cross-section calculation in gSeaGen (this depends on the underlying GENIE version), the apps/bjorkeny_dists programs should be run again to update the distribution file data/cross_sections_gSeaGen_v4r1/by_dists.root. Otherwise, the existing file can be used. The by_dists.root file is used by common_software/NuXsec.h/C class.

Available applications

As listed in the previous section, generic applications are available in the apps/ directory for data preparation for analysis with MONA. There are additional applications in the apps/ directory, which are typically accompanied with a README file to explain scope and usage.

ORCA Monte-Carlo chain and analysis format

ORCA Monte-Carlo chain

The typical ORCA MC chain consists of the applications and steps as illustrated below: ``` gSeaGen->KM3Sim JGandalf for tracks \ / \ JTE-> - -> merge, PID training –>summary / \ / mupage->KM3 Dusj reco for showers `` The summary files come from ECAP and are described in more detail at https://wiki.km3net.de/index.php/ORCA_PID. Basically it is one huge rootTTree` with all of the simulated events that contains all the information from the reconstruction algorithms, plus PID info and MC truth.

There are numerous gSeaGen and mupage files. We have something like gSeaGen_<flavor>_<interaction>_<erange>_<runnr>.root, where flavor is muon/elec/tau, interaction is CC or NC, erange is 1-5 or 3-100, runnr is 1-600.

This scheme persists until PID. However, in the PID summary file all flavours, interactions, energy ranges and run numbers are merged together, with special variables that help to re-trace the origin of each event. The merging is a necessary step for data input to machine-learning PID. On the other hand, for data sorting and quality purposes, having everything in one file is not always optimal (e.g. for effective mass calculations). Also, the ECAP PID output tree has about 300 branches, which occasionally change, depending on the version. Writing an analysis code that takes a changing and incomprehensible data format as input is not optimal. Because of this, the ECAP PID summary data is converted to analysis format (a smaller set of variables, organised tree, see below) and split up to match the file scheme used throughout the MC chain. Importantly, event filtering and the creation of corresponding detector responses, which is one of the base functionalities of the package, could not have been implemented without a well-defined format for the data.

Analysis format

The analysis format is defined by the class common_software/SummaryEvent.h/C. The class common_software/SummaryParser.h/C is set to read or write data in the analysis format by using the SummaryEvent class. The variables of the analysis format are described in SummaryEvent documentation.

Variables in tree

Quality levels

For each reconstruction there are branches called <reco>_ql0, <reco>_ql1, ..., where ql stands for quality level.

For ECAP April 2018 MC data We are usually advised to use ql1, as it selects more events and improves statistics. For shower there is no level 2 defined.

The quality levels are populated by the user in applications apps/data_sorting/Alpha(Beta...)ToSummary. In the end, it is up to the user to choose what sort of qualities these flags are used for. There is freedom to create custom quality cuts when PID tree is converted to summary formate, e.g. the user can create a new variable in the summary event ``` Double_t fTrack_ql3 = (nhits > 30) `` and use it when filtering events forEventSelectionandDetResponse`.