Project

General

Profile

Task #24529

Separate the neutrino energy calculation from EnergyReco_module.cc

Added by Dominic Brailsford 6 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Start date:
06/11/2020
Due date:
% Done:

90%

Estimated time:
Duration:

Description

The neutrino energy calculation is completely contained within EnergyReco_module.cc. This means that the only way to access the energy calculation is to run the module and then access the data product that it outputs. The energy reconstruction, coarsely speaking, is lepton energy + hadronic energy, where the lepton's energy is reconstructed via energy deposition summation (for showers) or ranging/MCS (for tracks).
This means that the energy reconstruction has to identify the lepton as part of the calculation, which is potentially at odds with downstream analyses which may choose a different object as the lepton.

It's also a bit cumbersome to have to access the data product to access the neutrino energy when the entire thing could be calculated in an outsourced function/algorithm.

I'd like to suggest that we alg-ify the energy reconstruction, so that the calculation is contained in an independent class which EnergyReco_module.cc can call as part of its operation. It also means that analysis code can run the energy reconstruction itself and choose which object is the lepton when requesting the neutrino energy.

As I'm suggesting it, and that the original author is no longer on the collaboration, I'm more than happy to do this task.

Just to be clear here, the changes wouldn't impact the final output of EnergyReco_module.cc at all, it would still be possible to make the neutrino energy data product in exactly the same way. However, analysers would have the option of running the energy reconstruction calculation themselves rather than having to run the ART module first.

numu_energydiff.png (5.15 KB) numu_energydiff.png Dominic Brailsford, 06/23/2020 01:51 PM
nue_energydiff.png (5.18 KB) nue_energydiff.png Dominic Brailsford, 06/23/2020 01:51 PM

History

#1 Updated by David Adams 6 months ago

I applaud moving algorithm code outside of modules so it can be used outside the art framework, e.g. in a standalone program or Root script.

I recommend an art tool for tasks like this so we have the dynamic loading and standard (fcl) configuration.

#2 Updated by Dominic Brailsford 5 months ago

  • % Done changed from 0 to 90
  • Status changed from New to Assigned

The separated algorithm has now been written. For now, it's written as an alg NOT wrapped in an ART tool (that refactor could come down the line).
The separated alg has a few overloaded public functions called CalculateNeutrinoEnergy.
The new alg code has also been plugged into the EnergyReco_module.cc module, but it currently sits side-by-side with all of the old reconstruction logic.

The CalculateNeutrinoEnergy functions that are called in the EnergyReco_module art module maintain the original reconstruction's logic: the alg makes decisions under the hood about whether to use ranging or MCS for the momentum reconstruction, whether to use the muon at all etc.
I've also included additional CalculateNeutrinoEnergy functions which explicitly demand that the neutrino energy is calculated via muon ranging or explicitly calculated via muon MCS. I'm hoping that the various functions cover all of the bases: It's possible to run the alg independently whilst still recovering the original reconstructions output (including the internal decisions) and it's also possible to reconstruct the neutrino energy under specific methods without any internal decisions being made.

I've got some local jobs running to verify that the old/new methods are completely consistent. I then need to do the final updates to the module itself to scrub out all of the old logic and add oxygen comments.

#3 Updated by Dominic Brailsford 5 months ago

Attached are plots showing the difference in the new and old energy reconstruction for both the numu and nue methods. I hope it's clear that the new/old methods are equivalent and the only difference is due to floating point error.

#4 Updated by Dominic Brailsford 5 months ago

  • Status changed from Assigned to Closed

The work is now completed and pushed to redmine's develop branch.

Also available in: Atom PDF