Trigger Data 2006 - unpacking

  1. L2 c-structs are now in CVS:
      StRoot/StDaqLib/TRG/L2gammaResult2006.h
      StRoot/StDaqLib/TRG/L2jetResults2006.h
      StRoot/StDaqLib/TRG/L2pedResults2006.h
    
     /star/u/akio/StEvent/StRoot/StEvent/
    
     StEnumerations.h
     StTriggerData.h
     StTriggerData2005.cxx
     StTriggerData2005.h
    
    int L2ResultsOffset(StL2AlgorithmId id, int run) const;
    bool IsL2Triggered(StL2TriggerId id, int run) const;
    
    StL2TriggerId in StEnumerations.h
    
    /afs/rhic.bnl.gov/star/packages/DEV/StRoot/StDaqLib/TRG/trgStructures2005.h
    
    

  2. You might want to look at the l1 trigger id, which is after pre- and re-scales but before l2. (l0 tcu bits are by definition before prescales). I think the decision to call l2 is based on the l1 trigger id, not the l0 trigger word (or tcu bits). Jamie

  3. There are three levels of trigger id's: l1, l2, l3, corresponding to three levels of labeling for accept. Different l2 algorithms run on the same l1 trigger id this year, so multiple trigger id's in the l2() level can correspond to one trigger id at the l1() level l3 can additionally relabel things, and has in the past, but I don't think this is being used this year, so is a duplicate of l2. nominal() usually points to l3(); Jamie

  4. triggerIdCollection()->l2().mask() should be the same as L2Sum[0]. Jamie

  5. I think (but I don't know) that the DATAP L2 summary is a copy of the L2Sum in the triggerData.Jamie

  6. he mapping between bit(daqTriggerId) and offlineTrgId changes from run to run: not fixed by a trgsetupname (this is why we need the database lookup).Jamie

  7. 2Sum[0] = 0? That would mean that the event didn't satisfy any offline trigger id, and so shouldn't be taken.Jamie

  8. If you want to check if it should be called, check the L1Sum[0] mask.is called "mask" in triggerIdCollection().l1().mask(),Jamie
    l1 : satisfied a certain trigger id at l0 and l1
    l2 : satisfied a certain trigger id at l0, l1, and l2

  9. the decision to run L2 is based on output from L1, not from L0. The event was taken by L0 for other reasons, not related to the base trigger id for L2, and did not satisfy the rescaling at L1 for that trigger id. The decision to run L2 is based on the output from L1, which flags events after rescaling, not on whether the event was taken at L0, as far as I understand. Jamie

  10. L1 has pre-scales and marks in L1Sum[0] in the trigger summary for a particular event when the prescale counters to zero. John

  11. L2Sum[0] has to do with the TRIGGER ID, which is given an arbitrary bit out of a 32-bit word for every run; if the event satisfies the trigger id that corresponds to that bit, the bit is set. Again, the bits are arbitrary. --Jamie

  12. I believe VTX[3]%512 returns the BBC E-W time difference. Only 4-bit reslution despite 9-bit range. in 2006, Jason

  13. BBC time difference with full 9-bit resolution is NOT recorded in the trigger data. Akio says: Closest is to find higher value (so it is NOT exact)
    maxE={BBClayer1[6], BBClayer1[4]}
     maxW={BBClayer1[2], BBClayer1[0]}
     diff=maxE-maxW
    

  14. TCU bits: http://www.star.bnl.gov/STAR/html/trg_l/run2006/TCU_Input_Bits_run2006.pdf
    bemc-jp0-etot-mb consists of bit (7.and.3.and.14).or.(8.and.3.and.14). For eemc-jp0-etot-mb, substitute bits 11 and 12 for 7 and 8 in the above. You cannot strictly do the equivalent at layer 2 DSM output, because you do not have access to minbias bit there. Steve V.

  15. ererally Lx_summary[0] is the mask of triggers satisfied AFTER level X. Jeff