Feature/bk finalize tme

[benkrikler]

I believe I've got the muon centred tree working (#110), or at least, the code compiles and runs. I need to do something with the TMEs before I can confirm that but I would like to do that on a separate branch.

The early and late TME flags are not implemented yet as I'm waiting to see how we implement obtaining TDiff values to help define the start and stop of each midas event.

I have changed some common files as well so this is to alert people to potential changes before I merge this. The changes to common files are:

• debug_tools.h now has a variadic DEBUG_VALUE which can take several values and print them all
• AlcapExcept provides the backtrace method mentioned on #188
• LoopSequence catches Alcap exceptions and prints the backtrace
• main.cpp was changed only to make sure we clear TMEs in ClearGlobalData.
• CreateModule.sh can now create TME generators

[AndrewEdmonds11]

This looks good, Ben.

Just to clarify what a TMuonEvent contains and does (plus a couple of questions), I see that a it has:

• a TDP for the central muon
• a list of TDPs from other sources that are within the time window (which can be retrieved and counted)
• a set of ExhaustedChannels (what are these for?)
• flags for setting whether the TME is late or early in the MIDAS event
• methods for determined whether there is pile up or a muon hit (surely all TMEs would have a muon hit in, no? Actually, I think I see now. Is it for the muPC cuts on the muSc hit? (which might not be a muon). But should this not happen in the TME generator?)

Also, could you give a brief explanation of the two generators we have?

[benkrikler]

• a TDP for the central muon
• a list of TDPs from other sources that are within the time window (which can be retrieved and counted)

The TDP for the central muon is (or at least should be) repeated in the list of muSc hits contained in fDetectors, but since these are all pointers to existing TDPs this is just a more useful way of organising the hits, since we define the time of the TME from the central muon pulse.

• a set of ExhaustedChannels (what are these for?)

This may be helpful in identifying whether or not a TME was near the end of a midas event for one channel. When a generator identifies that there are no more pulses left in a channel it sets the flag for that channel as exhausted.

• flags for setting whether the TME is late or early in the MIDAS event
• methods for determined whether there is pile up or a muon hit (surely all TMEs would have a muon hit in, no? Actually, I think I see now. Is it for the muPC cuts on the muSc hit? (which might not be a muon). But should this not happen in the TME generator?)

I've come to view the generators as tasked with filling the TME with pulses but leaving the logic as to whether a TME is late / early / a muon hit / muon pile-up as a part of the TME itself. When all these methods are fully implemented I'm expecting them to just the number of pulses within a specific set of channels to determine whether a TME has one of these properties.

Also, could you give a brief explanation of the two generators we have?

The MaxTimeDiff is the same algorithm as used for TDPs. It's output is a single set of correlated pulses. That was my orignal understanding of the muon centred tree so I re-used the algorithm as a first attempt at a generator. I think I should probably deprecate it though. The new FixedWindow generator implements things to match the definition of a TME from issue #110 where each channel can have multiple pulses. I don't expect we'll have many (if any) other TME generators to be honest, but the generator mechanism is still useful and re-uses the TAP mechanism so is little extra overhead to maintain.

[AndrewEdmonds11]

I've come to view the generators as tasked with filling the TME with pulses but leaving the logic as to whether a TME is late / early / a muon hit / muon pile-up as a part of the TME itself

I disagree. I think the generator should be creating TMEs that are definite muon events (i.e. it's pile-up protected and has a muon in it). I've been viewing any module post TME generation as our final physics plotters, whether it's for a dE/dx or a Ge spectrum. We don't want to be making the same selections in each plotting module to ensure we have a good selection of muons.

[benkrikler]

I disagree. I think the generator should be creating TMEs that are definite muon events (i.e. it's pile-up protected and has a muon in it)

As long as later analysis can tell whether or not a given TME is pile-up or a true hit I don't see any risk of them including the TME in the analysis when the analysis should be pile-up protected. The methods WasEarlyInEvent, WasLateInEvent, HasMuonHit and HasMuonPileup implement these flags so any physics / plotter can use them to confirm if a TME should be used for analysis. What's more, as John pointed out on #110, the pile-up itself may contain information so by keeping these events we can study just the pile-up itself.

[benkrikler]

Done! I reckon it might be good if we each do a run or two just to make sure everythings behaving as expected after the recent merges. I had a conflict in TAPAlgorithms.cpp so if either @jrquirk or @AndrewEdmonds11 could check that it looks as they had it before, that would be good.