Home

Getting started with PROfit: PROconfig the configuration XML

Everything that is user definable about the selection/spectra/systematics/binning and physics model is configurable at run time with a single configuration XML. All PROfit executables take the argument -x myconfig.xml or --xml myconfig.xml. Here we will describe the basic sections of a configuration xml

The Mode, Detector, Channel and binning (aka the Bookeeping Section)

<mode name="nu" />
<detector name="SBND" />
<detector name="ICARUS" />

<channel name="numu" unit="Reconstructed Neutrino Energy [GeV]">
    <bins edges="0.3 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 1.0 1.25 1.5 2.0 2.5 3.0"/>
    <truebins min="0" max="2" nbins="200"/>
    <subchannel name="cc" plotname="#nu_{#mu} CC" color="#FF6961"/>
    <subchannel name="nc" plotname="#nu_{#mu} NC" color = "#77DD77" />
    <subchannel name="cosmic" plotname="Cosmic" color = "#AEC6CF" />
</channel>

<channel name="nue" unit="Reconstructed Neutrino Energy [GeV]">
    <bins edges="0.0 0.2 0.4 0.8 1.0 1.5 2.0"/>
    <truebins min="0" max="2" nbins="200"/>
    <subchannel name="cc" plotname="#nu_{e} CC" color="#FF7962"/>
    <subchannel name="cosmic" plotname="Cosmic" color = "#77DD90" />
</channel>

The above code configures a single mode (nu), two detectors (SBND and ICARUS), each with two channels (numu and nue). In reality there is no difference between modes and detectors other than human interpretation. Channels are physical observable reco spectra in a variable with a specified reco binning (given by <bins>) and true binning (given by <truebins>). The classic example is reconstructed neutrino energy for reco variable and L/E for true variable for an oscillation fit, but it could be anything. Binning in truth and reco can vary between different channels.

Each channel is made up of any number of subchannels which consist of truth level breakdowns of the prediction, broken down because we want to either (a) Have our model act differently on each subchannel, such as numu's and nue's oscillaating differently (b) Apply systematic differently to subchannels. The subchannels are a truth level definition and are not physical, we can't say if an even in data i from a particular subchannel, just the parent channel. When we want to do fits we collapse the subchannels, adding their events into a single channel spectra. By construction each subchannel in a given channel must have the same binning as each other in order to collapse correctly.

In this example we have subchannels such as NC and CC events as well as a cosmic background category.

The mode, detector, channel and subchannel tags must not contains underscores (_) be unique when concatenated together into a single spectra identifier using underscores mode_detector_channel_subchannel. This unique identifier is used later to tell PROfit exactly which Monte Carlo events to fill into each spectra.

At this stage we have not defined what the variable is, or how to fill it from MC, this is just a bookeeping step to define exactly the binning and spectra we want to fill. Filling it is defined later when we get to the MCfile portion.

The model_rule section (aka defining the physics model)

This section is incomplete but allows for the definition of all physics "rules" that should be applied to any given subchannel defined above. Similar to the channel and subchannel above, this section spells out the bookeeping of the model, but the physics itself is described elsewhere (currently in the PROsc.c class itself.)

<model tag="3plus1">
    <rule index="0" name="No Osc"/>
    <rule index="1" name="Numu Dis"/>
    <rule index="2" name="Nue App"/>
</model>

The above tells us that in the model "3+1" we will have three possible rules, identified by the index's 0,1,2 and correspond to No Osc, NuMU appearance and NuApp. Mode index 0 should always correspond to no-effect and subchannels will default to this if none other are given.

The MCfile section (aka where does our Monte Carlo go?)

This is the most important, but complex XML element. It explains what, where and why in regards the defined subchannels of the analysis. Here is a example snapshot of two MCFiles.

<MCFile treename="events/selectedNu" filename="my_fake_numufile.root" scale = "1.0" maxevents="50000" pot="1"> 
    <friend treename="events/multisimTree" filename="selmy_fake_numufile.roott"/>
    <friend treename="events/multisigmaTree" filename="my_fake_numufile.root"/>
     <branch
         associated_subchannel = "nu_SBND_numu_cc"
         name                  = "recoE"
         model_rule            = "1"
         true_param_name       = "trueE" 
         true_L_name           = "trueL / 1000"
         pdg_name              = "truePDG"
         additional_weight     = "CC==1"
         />
</MCFile>

<MCFile treename="events/selectedNu" filename="my_fake_nuefile.root" scale = "1.0" maxevents="50000" pot="1"> 
    <friend treename="events/multisimTree" filename="my_fake_nuefile.root"/>
    <friend treename="events/multisigmaTree" filename="my_fake_nuefile.root"/>
     <branch
         associated_subchannel = "nu_SBND_nue_nc"
         name                  = "recoE"
         model_rule            = "1"
         true_param_name       = "trueE" 
         true_L_name           = "trueL / 1000"
         pdg_name              = "truePDG"
         additional_weight     = "0.3"
         />
</MCFile>

The first few attributes give the filename (aka full path to the file) and the treename to load. Now we often have many trees in a file, so the friend element allows for friending any umber of TTrees from the same or multiple files.

The most important aspect is the branch tag with the following attributes

• associated_subchannel : This is the subchannel to fill with this file (in mode_detector_channel_subchannel unique tag defined above)
• name : Its called name, but this is the actual formula to fill into the subchannel (it can be anything a TTreeFormula can take, so any function of branch names
• model_rule : What rule to apply? Use the index defined in model above. defaults to 0, i.e no rule.
• true_param_name : The truth formula, again anything a TTreeFormula or TTree->Draw() can use.
• true_L_name : Will make this more generic soon in regards any umber of truth variables, hard coded for L: baseline right now. Again a TTreeFormula enabled input.
• pdg_name : Not currently used, oscillated via model rules as described above.
• additional_weight : Can be a cut (defined as any TTreeFormula) or scaling to apply event by event.

Making a quick sensitivity contour