<br><br><div class="gmail_quote">On Wed, Jul 14, 2010 at 11:14 AM, Brad Sawatzky <<a href="mailto:brads@jlab.org">brads@jlab.org</a>> wrote:<br><blockquote class="gmail_quote">
<div>On Tue, 13 Jul 2010, David Flay wrote:<br>
<br>
</div><div>> On Tue, Jul 13, 2010 at 2:06 PM, Brad Sawatzky <<a href="mailto:brads@jlab.org">brads@jlab.org</a>> wrote:<br>
><br>
> > The 'eff' value for T4 doesn't really mean much. (It isn't really an<br>
> > efficiency by any standard definition -- I wouldn't worry about it.)<br>
> ><br>
> > Now that I think about it a bit more (and I'm suspicious that the<br>
> > efficiency seems too good to be real), I forgot a some factors in the<br>
> > expression I gave you. The trigger counts really ought to be multiplied<br>
> > by the prescale factors<br>
> > eff_3 = bit3*ps1/(bit3*ps1 + bit4*ps4)<br>
> ><br>
> > You'll need to grab the prescales from the ROOT file on every run since<br>
> > they can change, of course.<br>
> ><br>
><br>
> Wouldn't including the prescales give the latch pattern variable -- LTN =<br>
> ps*bitN? Since bitN is after the prescale.<br>
<br>
</div>That's correct, but I don't think the LTN are the latched triggers. We<br>
still need to use the prescales though. Imagine that the T3 trigger was<br>
only 50% efficient, but ps4 was set to be 10^6; The calculation would<br>
give eff_3 = 1 because all the T4's got prescaled away.<br></blockquote><div><br>This makes sense -- I think my interpretation of what the latch pattern is was incorrect. (compared to your description below)<br><br></div>
<blockquote class="gmail_quote">
The db_DL.dat file claims the LTN variables are 'trigger input LHRS copy<br>
in 1877', so it sounds like they are before prescale (which could<br>
explain the T4 discrepancy you saw).<br>
<br>
The 'LHRS trigger latch pattern' comment is attached to the lbitN<br>
variables.<br>
<div><br>
> I know that we're missing events in that despite ps = 1 for T3 and T4 for<br>
> run 20676 (from the<br>
</div>> logbook<<a href="http://www.jlab.org/%7Eadaq/halog/html/0903_archive/090314032236.html">http://www.jlab.org/%7Eadaq/halog/html/0903_archive/090314032236.html</a>>):<br>
<div>> the LT3 doesn't match bit3 (and more noticeable is the discrepancy of<br>
> the T4 values) :<br>
><br>
> Trigger 3 [Bit]: 13870<br>
> Trigger 4 [Bit]: 10<br>
> Trigger 3 [Latch]: 13885<br>
> Trigger 4 [Latch]: 314<br>
> T3 Trigger Efficiency [using bit variables]:<br>
> Trigger 3: 99.9280 +/- 0.0228%<br>
><br>
> (where I count the number of entries in the histos for 'DL.bit3', etc.)<br>
<br>
</div>Just a word of caution here. Might not matter for the work you're<br>
doing, but you should be aware of this:<br>
<br>
You need to be a bit careful with the evtypebits, DL.bit*, DL.lbit* stuff.<br>
The .bit* and .lbit* are (iirc) just raw TDC data. The evtypebits is<br>
constructed from the DL.bit* TDC data by applying a _very_ loose cut.<br>
<br>
A 'real' bit3 will be a hit in the DL.bit3 histogram that lands in a<br>
self timing spike (ie. a fairly narrow cut). In practice, a lot of<br>
folks forget about that and just do stuff like (DL.bit3 > 0) to see if<br>
there was a hit on T3 -- that will catch anything in that TDC channel<br>
within a microsecond of the L1A. Not what you usually want.<br></blockquote><blockquote class="gmail_quote">
The cut on the .bit* histos that is used to make evtypebits is also<br>
pretty loose (like 200 < DL.bit3 < 2000) -- which is OK if you have a<br>
low rate trigger, but not so good if your trigger rate is high and<br>
you're trying to be precise.<br></blockquote><div><br>The trigger rate for this run (T3, that is) is ~ 440 Hz (from the halog); so that's not necessarily high<br>I also have a variable printing out from the replay, and I get ~460 Hz -- so there's some discrepancy there...<br>
<br></div><blockquote class="gmail_quote">
The trigger latch pattern is also a bit arbitrary. The way that works<br>
is that the Trigger supervisor sees N triggers on its inputs, the<br>
earliest trigger that passes prescale generates the L1A. Any triggers<br>
that arrive within XXX ns of the 'L1A' trigger get latched on the output<br>
that goes to the DL.lbit* TDC channels. (The XXX is programmable in the<br>
TS and is typically set to 10ns.) This is fine, but is only useful if<br>
all of the interesting triggers are tweaked so they will arrive within<br>
the 10ns of each other at the TS. That is often NOT the case, which<br>
limits the utility of the 'official' TS latch pattern (lbitN).<br></blockquote><div><br>so the 'latch pattern' essentially stores those triggers that came within XXX ns of the L1A trigger in the DL.lbit* variable?<br>
(and is NOT the 'before prescale' trigger as I was initially thinking)<br> <br><blockquote class="gmail_quote">
> PS -- should Cherenkov TDC cuts be used here? I tried it out, and I get<br>
> eff_T3 ~ 99.96%, as compared to above, at 99.92%.<br>
> I tacked on the TDC cuts since I do use them to define good<br>
> electrons in the Cherenkov.<br></blockquote>
</div><blockquote class="gmail_quote">
It is best to tack them on just to be consistent -- I'm surprised it<br>
makes any difference since you're already cutting on the cerenkov ADC<br>
sum. Mind you, 4 parts in 10000 isn't really significant for that<br>
quantity.<br></blockquote><div><br>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. <br>
<br></div><blockquote class="gmail_quote">
<div><br>
> Also -- I was looking at Patricia's work on the trigger efficiency<br>
> -- her left arm results are comparable to mine (99.98%):<br>
> <a href="http://hallaweb.jlab.org/experiment/E01-012/reports/trig_vdc.pdf">http://hallaweb.jlab.org/experiment/E01-012/reports/trig_vdc.pdf</a><br>
> However, she is fairly brief on her description of the calculation.<br>
<br>
</div>Glad to see the consistency with older work.<br clear="all"></blockquote><div><br>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). <br>
<br>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) <br><br></div></div>