TriggerDataDecoder and MRDTracks minor bug fix

[S81D]

Modify the TriggerDataDecoder tool to increase its performance:

• Triggers stored to the buffer are now cleared
• add verbosity thresholds for some std out messages

Change the FindMRDTracks so that if the tool doesn't find MRD data it spits out an error message instead of haulting the entire toolchain

[S81D]

Also fixed the config file for the EventBuilderRaw toolchain that can be used to generate raw waveforms in the Processed file (useful for the AmBe analysis).

[S81D]

CreateMyList.sh is used to generate the my_files.txt list for running the PreProcessing toolchain that generates the TrigOverlap files. Just removed an argument that asks for the path to the RAWData and added a hard coded path, as it doesn't move locations. That way you simply need to provide the Run number.

[S81D]

@marc1uk regarding the comments you gave me during the software call:

• For the TriggerDataDecoder, we added clearing the buffer similar to the "Monitoring" mode of the tool:

  ToolAnalysis/UserTools/TriggerDataDecoder/TriggerDataDecoder.cpp

  Line 142 in 2049927

  processed_sources.clear();

  . If the mode is "Monitoring" the buffer TimeToTriggerMap is cleared, but for the "EventBuilding" mode, it is not cleared. This normally isn't a problem in the event building toolchain as the buffer will be cleaned/cleared by removing paired entries by another tool. But for other toolchains that use the TriggerDataDecoder tool (like the BeamFetcherV2 toolchain), there is no other tool to do the clearing, so when running over multiple part files it really slows down as the buffer continues to grow.

• For the FindMRDTracks, the reason we commented out the line was to avoid grabbing an empty triggerword from the Store: get_ok = m_data->Stores["ANNIEEvent"]->Get("TriggerWord",TriggerWord);. For the old event builder this object (always a single trigger word) was at the base of pairing events, so it should never be empty (and not raise the error). In contrast, the new event builder groups all triggers involved in an event (triggers telling the CTC the beam is coming, then the triggers sent by the CTC to the ADC/TDC to start recording data). I have reverted the change to keep in place the stop toolchain feature in case it can't find a triggerword. We changed some of the new event building to make sure this object is populated with the correct "traditional" trigger words that other downstream tools rely on.

[marc1uk]

awesome, thanks for looking into it and for the explanations 👍 🎉