[d2n-analysis-talk] LHRS Trigger Efficiency Study

[David Flay]

On Wed, Jul 14, 2010 at 11:14 AM, Brad Sawatzky <brads at jlab.org> wrote:

> On Tue, 13 Jul 2010, David Flay wrote:
>
> > On Tue, Jul 13, 2010 at 2:06 PM, Brad Sawatzky <brads at jlab.org> wrote:
> >
> > > The 'eff' value for T4 doesn't really mean much.  (It isn't really an
> > > efficiency by any standard definition -- I wouldn't worry about it.)
> > >
> > > Now that I think about it a bit more (and I'm suspicious that the
> > > efficiency seems too good to be real), I forgot a some factors in the
> > > expression I gave you.  The trigger counts really ought to be
> multiplied
> > > by the prescale factors
> > >  eff_3 = bit3*ps1/(bit3*ps1 + bit4*ps4)
> > >
> > > You'll need to grab the prescales from the ROOT file on every run since
> > > they can change, of course.
> > >
> >
> > Wouldn't including the prescales give the latch pattern variable -- LTN =
> > ps*bitN?  Since bitN is after the prescale.
>
> That's correct, but I don't think the LTN are the latched triggers.  We
> still need to use the prescales though.  Imagine that the T3 trigger was
> only 50% efficient, but ps4 was set to be 10^6; The calculation would
> give eff_3 = 1 because all the T4's got prescaled away.
>

This makes sense -- I think my interpretation of what the latch pattern is
was incorrect. (compared to your description below)

The db_DL.dat file claims the LTN variables are 'trigger input LHRS copy
> in 1877', so it sounds like they are before prescale (which could
> explain the T4 discrepancy you saw).
>
> The 'LHRS trigger latch pattern' comment is attached to the lbitN
> variables.
>
> > I know that we're missing events in that despite ps = 1 for T3 and T4 for
> > run 20676 (from the
> > logbook<
> http://www.jlab.org/%7Eadaq/halog/html/0903_archive/090314032236.html>):
> > the LT3 doesn't match bit3 (and more noticeable is the discrepancy of
> > the T4 values) :
> >
> > Trigger 3 [Bit]: 13870
> > Trigger 4 [Bit]: 10
> > Trigger 3 [Latch]: 13885
> > Trigger 4 [Latch]: 314
> > T3 Trigger Efficiency [using bit variables]:
> > Trigger 3: 99.9280 +/- 0.0228%
> >
> > (where I count the number of entries in the histos for 'DL.bit3', etc.)
>
> Just a word of caution here.  Might not matter for the work you're
> doing, but you should be aware of this:
>
> You need to be a bit careful with the evtypebits, DL.bit*, DL.lbit* stuff.
> The .bit* and .lbit* are (iirc) just raw TDC data.  The evtypebits is
> constructed from the DL.bit* TDC data by applying a _very_ loose cut.
>
> A 'real' bit3 will be a hit in the DL.bit3 histogram that lands in a
> self timing spike (ie. a fairly narrow cut).  In practice, a lot of
> folks forget about that and just do stuff like (DL.bit3 > 0) to see if
> there was a hit on T3 -- that will catch anything in that TDC channel
> within a microsecond of the L1A.  Not what you usually want.
>
The cut on the .bit* histos that is used to make evtypebits is also
> pretty loose (like 200 < DL.bit3 < 2000) -- which is OK if you have a
> low rate trigger, but not so good if your trigger rate is high and
> you're trying to be precise.
>

The trigger rate for this run (T3, that is) is ~ 440 Hz (from the halog); so
that's not necessarily high
I also have a variable printing out from the replay, and I get ~460 Hz -- so
there's some discrepancy there...

The trigger latch pattern is also a bit arbitrary.  The way that works
> is that the Trigger supervisor sees N triggers on its inputs, the
> earliest trigger that passes prescale generates the L1A.  Any triggers
> that arrive within XXX ns of the 'L1A' trigger get latched on the output
> that goes to the DL.lbit* TDC channels.   (The XXX is programmable in the
> TS and is typically set to 10ns.)  This is fine, but is only useful if
> all of the interesting triggers are tweaked so they will arrive within
> the 10ns of each other at the TS.  That is often NOT the case, which
> limits the utility of the 'official' TS latch pattern (lbitN).
>

so the 'latch pattern' essentially stores those triggers that came within
XXX ns of the L1A trigger in the DL.lbit* variable?
(and is NOT the 'before prescale' trigger as I was initially thinking)


> > PS -- should Cherenkov TDC cuts be used here?  I tried it out, and I get
> > eff_T3 ~ 99.96%, as compared to above, at 99.92%.
> >         I tacked on the TDC cuts since I do use them to define good
> > electrons in the Cherenkov.
>
 It is best to tack them on just to be consistent -- I'm surprised it
> makes any difference since you're already cutting on the cerenkov ADC
> sum.  Mind you, 4 parts in 10000 isn't really significant for that
> quantity.
>

This small change was odd to me too, but like you said, not terribly
significant. I'll include them though; considering it goes along with my
definition of good electrons in the Cherenkov.


>
> >         Also -- I was looking at Patricia's work on the trigger
> efficiency
> > -- her left arm results are comparable to mine (99.98%):
> > http://hallaweb.jlab.org/experiment/E01-012/reports/trig_vdc.pdf
> >         However, she is fairly brief on her description of the
> calculation.
>
> Glad to see the consistency with older work.
>

So, I'll add in the prescales to the calculation, and see how it comes out
run-by-run.  (run 20676 is good as it is, since ps=1 for both T3 and T4 in
this case).

Is there a variable in EPICS to get the prescale? (the link you sent out
mid-June about the EPICS variables doesn't seem to work)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/d2n-analysis-talk/attachments/20100714/4385cb63/attachment.html