Overview of the project

The layout of the project includes three types of classes:

Main RB Classes

Likelihood functions

• Grab any necessary data from the frame

• Orgainize individual detectors as needed (ex: into triggered/untriggered)

• Iterate over detectors in the array, calculating a local likelihood (LH) for each one and returning the global log-likelihood, specifically sum[ +ln(LH) ] and not a chi-sq or -2ln(LH)

• see: rock_bottom/private/rock_bottom/interface/<detector_type> for examples

Signal Models

• These do most of the “heavy lifting” for each detector type in regards to detector-specific calculations

• Include a number of functions that can be called by the Likelihood class to determine the global likelihood of the event

• All (or almost all) of the “special numbers” for each detector should be here

• These effectively handle the seed-setting work for fit functions and thus have also hold any default parameters for the detector (ex: reference distance)

• see: rock_bottom/private/rock_bottom/models/<detector_type> for examples

Shower Development Functions

• These are functional forms describing the shape of the shower. Currently, these are either an LDF or a shower-front description

• see: rock_bottom/private/rock_bottom/functions/<detector_type> for examples

In principle, a reconstruction can be performed with any combination of these, though this up to the developer(s) of the specific detector.

Flow of data during an event reco

These various classes must be linked together so that they can perform the necessary calculations.

Before the reconstruction begins, the frame is made available to the log-liklihood function (e.g. I3RbLDFLikelihood). The frame is then passed along to the linked signal model (e.g. I3LaputopSignalModel). Both objects extract any information from the frame that is deemed relevant. Once the reconstruction beings, at each minimization iteration, the I3EventHypothesis (a combination object that contains an I3Particle and a I3RbParameterMap) is given to the LLH and is passed along to the signal model. The LLH is calculated using the current hypothesis and the observed signals.

Notes for Developers

If you would like to make your own model (for an existing detector) and/or your own likelihood (if you want to add a new detector) you can look at the “skeleton” examples in rock_bottom/resources/skeleton (or see Skeletons) as a place to start.

Guidelines

• Avoid adding (and certainly do not remove) anything in the base classes and do not add any “special numbers” there.

  Exception: It may be that you need a new parameter in the likelihoodBase

• In the likelihoods, it is advised that you do NOT do any math there besides calculating your likelihood. It is best to leave this to the models.

• Likelihood functions make no decisions.

• No ‘global’ corrections are applied inside the likelihood. For example, these can be done by another module or at least factored out (they are likely to change):

  • s_125 -> energy conversion

  • global pressure correction

• Flags indicating tank/DOM status should be explicitly stored in the event interface. In other words: we want to keep track of which tanks were used by the fitting module

• The likelihood must return +ln(LH), not -ln(LH) or a Chi-sq. The addition of LLHs between detector arrays is only meaningful if we are adding the same thing

• It may be that you want to pass a new parameter to your model, (ex. the high above ground of the scint), simply add this to the RockBall class