[d2n-analysis-talk] Comparison of DL.bit3 to DL.LT3 (BigBite folks should read this too)

[Brad Sawatzky]

On Fri, 20 Aug 2010, David Flay wrote:

[ . . . ]
> Now, if we consider how the evtypebits is built (looking at the DecData
> class),
> 
> //_____________________________________________________________________________
> void THaDecData::TrigBits(UInt_t ibit, BdataLoc *dataloc) {
> // Figure out which triggers got a hit.  These are multihit TDCs, so we
> // need to sort out which hit we want to take by applying cuts.
> 
>   if( ibit >= kBitsPerByte*sizeof(UInt_t) ) return; //Limit of evtypebits
>   bits.ResetBitNumber(ibit);
> 
>   const UInt_t cutlo = 200;
>   const UInt_t cuthi = 1500;
> 
>   for (int ihit = 0; ihit < dataloc->NumHits(); ihit++) {
>     if (dataloc->Get(ihit) > cutlo && dataloc->Get(ihit) < cuthi) {
>       bits.SetBitNumber(ibit);
>       evtypebits |= BIT(ibit);
>     }
>   }
> 
> //______________________________________________________________________________
> 
> which shows that the evtypebits is set whenever we have a hit in the
> TDC within the cut window (for the variable DL.bitN, I believe).   So
> events that fall within the cut window are the good ones -- whereas,
> looking at

No, events that land in the self-timing peak are good ones.  The rest
are crap.

Both DL.bit3 and DL.LT3 are just TDC histograms -- there's nothing
special about them.  So, the events in the self-timing spike are those
where that trigger carried the L1A timing.  If you have a hit outside
the spike, then it means it was not involved in the trigger.  The
cluster of hits 200--400 channels to the left of the self-timing peak
are hits that arrive 100--200ns (1877 TDC) *after* whatever formed the
event trigger.  It would be interesting to see if those 'late' hits are
actually correlated with 'good' hits or not (recall that the 1877 is
multi-hit:  you could be double-counting in the DL.bit3 histogram.
Perhaps the bit3 channel is seeing two hits for ~1% of the events -- one
in the self-timing and a second in the broader peak to the left
(after-pulse, electronic glitch, etc).  Please check this and report on
it next meeting.

FWIW, this is what I was talking about ages ago when I was harping about
the 'default' evtypebits cuts being too loose.  I thought it had been
fixed.

Note that the same analysis needs to be done on the BigBite side.  It is
a little more complicated there though because the TDC common stop is
retimed off the shower (rather than coming directly from the L1A) -- so
you shouldn't expect a single channel self-timing spike but some fairly
narrow structure instead.


Back to your histos.  The fact that there are hits thousands of channels
away from the self-timing peak in DL.LT3 makes me question whether that
is really a copy of the latch pattern at all.  My understanding was that
the TS would only pass the "Latch" bits if they arrived within ~10ns
(programmable) of the initiating trigger.  That is inconsistent with the
DL.LT3 histogram you show here...

OK, when I look into a semi-random db_DL.dat file in our DB_DIR, I see
these entries:
# LHRS trigger bit pattern(prescaled)
bit1       crate      4    13       0
bit2       crate      4    13       1
...

# LHRS trigger latch pattern
lbit1       crate      4    13       13
lbit2       crate      4    13       14
...

# trigger input LHRS copy in 1877
LT1        crate      4     9      48
LT2        crate      4     9      49
...

Here's a summary based on the db_* file comments:
  - LTN is _not_ a latch pattern, but a copy of the trigger input
    (before prescale) to the TS -- that makes more sense.
  - bitN is the after-prescale copy of the triggers.
  - lbitN should be the latch pattern.  I spent some time digging into
    exactly how this is constructed by the TS, and I have strong
    suspicions that the "TS latch pattern" isn't particularly useful to
    us.  I am curious to see what it looks like though...

> Based on this, I think the correct variable to be using in the T3
> Trigger (for good electrons) Efficiency study is the DL.bitN variable.

I think bitN is the correct variable to look at, but you (and Matt,
Diana) need to confirm that the DecData 'evtypbits' cuts are not going
to count garbage (or double-count) because they are unnecessarily wide.

-- Brad

-- 
Brad Sawatzky, PhD <brads at jlab.org>  -<>-  Jefferson Lab / Hall C / C111
Ph: 757-269-5947  -<>-  Fax: 757-269-5235  -<>- Pager: brads-page at jlab.org
The most exciting phrase to hear in science, the one that heralds new
  discoveries, is not "Eureka!" but "That's funny..."   -- Isaac Asimov