PDS Triggering

[CharlieBatchelor]

Overview & Goal

As discussed in the Data Selection and Physics Performance meeting, it would be good to start prototyping something like a PDS and TPC triggering chain. It's expected that something like a TP will be delivered to the trigger system via the DAPHNE boards. Currently, this isn't implemented, and the best I have is to use some existing DAPHNE waveforms, run a hit finder (very similar to what we initially had for SW TPG) and generate a TP list that can be supplied to the TP Replay app.

I've made a toy model of this project, here. The main.py script will generate a list of PDS style TPs, as shown in the README on that page. If we can artificially align some of these PDS TPs with some TPC TPs from the coldbox, then we can emulate some (admittedly very rough) PDS and TPC coincidence triggering sequence.

Task List

• [x] Implement a PDS TAMaker and TCMaker.
• [x] Generate a list of PDS TPs (or something that looks like a list of PDS TPs) and push them through the replay app, using that new algorithm.
• [x] Finally, test with the HorizontalMuon or PlaneCoincidence trigger algorithms concurrently, with the new method developed in #202.

[CharlieBatchelor]

New branches of detdataformats, trigger and triggeralgs have been made with new TXMakers called TriggerActivityMakerPDS and TriggerCandidateMakerPDS. These are based on the simple Prescale algorithm plugins, since the type of triggering we will do on PDS is very simple counting (most likely).

The branches are all called: cbatchelor/pds_algorithm

Next steps are to use my PDS hit finding toy to generate a list of hits I can play through the replay app.

[CharlieBatchelor]

Okay looks good. Using a configuration like the following, I can supply a list of 'PDS TPs' to the replay app and trigger on them, where the TAs and TCs will be marked in the logs with:

04-12 11:42:29.513410 TriggerActivityMakerPDS LOG operator()(const triggeralgs::TriggerPrimitive&, std::vector<triggeralgs::TriggerActivity>&): Emitting PDS Trigger Activity 100

Configuration Generation Command:

python -m trigger.replay_tp_to_chain -s 50 --trigger-activity-plugin TriggerActivityMakerPDSPlugin --trigger-activity-config 'dict(prescale=100)' --trigger-candidate-plugin TriggerCandidateMakerPDSPlugin --trigger-candidate-config 'dict(prescale=100)' -l -1 --input-file $TPDATA/pds_tps_60s.txt json

[CharlieBatchelor]

By merging with the recent changes for concurrent algorithms in #202, I can run the above PDS TAMaker and HorizontalMuon TAMaker together, with two different input streams (TPC TPs and 'PDS TPs'), and see output from both in the logs:

04-12 15:27:19.596413 TriggerActivityMakerPDS LOG operator()(const triggeralgs::TriggerPrimitive&, std::vector<triggeralgs::TriggerActivity>&): Emitting PDS Trigger Activity 46400 04-12 15:27:19.596786 TriggerActivityMakerHorizontalMuon ALERT operator()(const triggeralgs::TriggerPrimitive&, std::vector<triggeralgs::TriggerActivity>&): Emitting track and multiplicity TA with adjacency 123 and multiplicity 247. The ADC integral of this TA is 12469 and the largest longest track seen so far is 123

[CharlieBatchelor]

Seeing an error when trying to use the two input streams now, will need to look at this tomorrow. Error is:

Connection Instance not found for name tpsets_rulocalhost_0_link1

I'm wondering if the way we fake the hardware map generation is causing the naming of connections to be something unexpected.

UPDATE:

This issue helped me to see that we were faking the hardware_map.txt file in a bad way, that meant when trying to use the replay app with more than one 'link', it wasn't generating a suitable configuration. I've fixed this in #202.

[CharlieBatchelor]

I can run and store triggers with the concurrent algorithm approach discussed above. The PDS TAMaker sees only PDS TPs, the TPC TAMaker sees both however. The attached diagram should help to visualise what has been done here.

TPC_PDS_Triggering.pdf

Note:

The TPSetTee-ing isn't necessary here. A distributor should be implemented based on input_tp.type, which splits and delivers the TPC and PDS TPs to their corresponding TAMakers.