Refactor Pulse Analysis
Context
The Pulse Analysis subsystem is responsible for analyzing and fitting pulses after they are found.
Summary
This MR adds the structures and class relationships necessary to allow Pulse Analysis algorithm implementations to be easily added to the project under code/pulse_analysis
. The actual implementation class (PulseFittingStrategy1
) is a no-op since we don't have enough time left to bring that feature over from the legacy code. The pattern here is the same as the one used for the Pulse Finding code; the PulseAnalysisProcessor
called from the RunManager is responsible for mapping the specified strategy class to each channel and then processing Event
objects one by one. Right now, the int
return value of PulseFindingProcessor::processEvent()
is effectively just used as a boolean to determine whether or not an event was analyzed or skipped.
Note: the naming difference between the higher-level "PulseAnalysis" classes and the concrete "PulseFitting" classes was intentional -- the thinking is that the looser interface would allow different kinds of analysis-related strategy classes to be added in the future.
How was this tested?
Built and ran the branch with our test config and everything seems to be working.
Sample output
(No pulses are skipped because PulseFittingStrategy1::analyze()
is hardcoded.