BEMC-Decoupled Trigger Utilities For PicoDst Production (Brief and User Relevant)

I have been working on isolating and extracting the relevant BEMC trigger code from StTriggerSimuMaker in order to simulate and store the trigger information in picoDst production from MuDsts. In my previous blog entry I outlined some of the specifics of what the code does and how to follow it. In this blog entry I hope to provide the relevant information regarding use of my code and some of the decisions that I needed to make.

Base Function:
For the time being, I have named the directory holding my make StSimpleTriggerUtilties, and its head maker StSimpleTrigSimuMaker. I extracted the relevant code to simulate the HT and JP triggers. To be as brief as possible, the code does two things:

0) Read in and store the thresholds for bemc high tower and bemc jp triggers.

1) Read in bemc hit information and calculate the tower dsmADC and jet patch dsmADC values and store them

The actually comparison between the dsmADC values and the threshold values is done in StPicoDstMaker. Someone (I am not sure who) has already coded in filling picoDsts with bemcTrigger information, and I mimicked storing the information in the same way. The code to fill the bemc trigger information in StPicoDstMaker is as follows:

0) In StPicoDstMaker, the HT thresholds are stored. There are up to 5 BHT thresholds (BHT0...BHT4), but I currently only store 4 of them, BHT0...BHT3. I can't seem to find the use of BHT4 in physics triggers , and it wasn't originally stored either.

1) Then the code loops over all 4800 towers, retrieving the dsmADC value from my StSimpleTriggerUtilities, and comparing it to each of the thresholds. If the dsmADC value exceeds the threshold, then an unsigned int variable named flag has one of its bits set to 1. The bit which is set to 1 corresponds to which threshold was exceeded. For the HT it is simple, 0th bit implies BHT0 was exceeded, 1st bit implies BHT1 was exceeded, and so forth up until BHT4.

2) If flag has any bits set to 1, then that implies that a trigger would have been fired. If this is the case then an StPicoEmcTrigger object is created, which holds 3 numbers. First it holds the flag. Second it holds the towerId. Third it holds the dsmADC value of the tower. Then the StPicoEmcTrigger object is stored.

3) Now the JP thresholds are stored. There are usually 3 JP thresholds (JP0,JP1,JP2). However, for part of 2015, there are 3 copies of the JP2 trigger, one for East, Mid and West. To decide how many JP triggers there are, I have to account for 2015 differently and check if the DSM register that would correspond to JP2 West is filled.  I need to check the specific register ONLY for 2015, as for 2013 the specific register holds the dijet trigger threshold. More information is outlined in my previous detailed blog post.

4) The code loops over 18 jet patches, retrieving the dsmADC value from StSimpleTirggerUtilities and comparing it to each of the thresholds. If the dsmADC value exceeds the threshold, then another unsigned int variable named flag has one of its bits set to 1. This time however, the bit set to 1 starts from the 6th bit (note I am using 0-indexing). This means that the 6th bit corresponds to JP0, 7th bit to JP1, and 8th bit to JP2. In the case of 2015, the 8th bit may correspond to JP2 east. If this is the case, then the 9th bit would be JP2 mid, and the 10th bit would be JP2 west.

5) If flag has any bits set to 1, then that implies that a trigger would have been fired. If this is the case then an StPicoEmcTrigger object is created, which holds 3 numbers. First it holds the flag. Second it holds the jetpatch Id. Third it holds the dsmADC value of the jet patch . Then the StPicoEmcTrigger object is stored.

Here is the table of bits which correspond to different thresholds:

Bit Trigger Threshold
0 BHT0
1 BHT1
2 BHT2
3 BHT3
4 BHT4
5 Unused
6 JP0
7 JP1
8 JP2 (east)
9 JP2 mid
10 JP2 west
11 Unused
12 Unused

If an event has only 1 tower which exceeded a threshold, say BHT1, and only 1 jet which exceeded a jet patch threshold, then there will be two emcTrigger objects. The first, would have a flag = 0011 = 3, corresponding to BHT0 and BHT1. The second would have a flag corresponding to flag = 100000 = 64

It is important to note that the Id stored in StPicoEmcTrigger may correspond to a tower Id or jet patch Id. There is no ambiguity, as if one is looking for jet patch triggers they would be searching through bits higher than 5, and if one is looking for high tower triggers, they would be searching through bits lower than 5. Because of the way the information is stored. flag will ONLY have bits non zero located above the 5th bit, XOR below the 5th bit.

Although this method of storing the trigger information may not be the most user friendly, it is space efficient and general. Because the amount of triggers can change for year to year, such as for 2015 there being 5 jet patch triggers instead of 3, I think this a an efficient way of handling it. Another way I can imagine is to store the strings "JP0" or "BHT2", but it is not as size efficient.

An example of a user using the bemcTrigger information from the PicoDsts for analysis would be: loop over StPicoEmcTriggers, search for the flag passing some condition (such has flag & 0x4 == 1 to check for BHT2) to check to see if a specific threshold has been exceeded. Then check to see if the tower which fired the trigger is good from their own good/bad tower list if they have one.

The obviously drawback is that this isn't the most user friendly way to store the trigger information, but it is rather space efficient. If this seems unsatisfactory, another option is to add a function in StPicoEvent which interprets the emcTrigger info and displays it in a more user friendly manner.