Re: [BLAST_SHIFTS] [BLAST_ANAWARE] more deadtime

From: vitaliy ziskin (vziskin@lns.mit.edu)
Date: Fri Mar 05 2004 - 10:59:20 EST


Mike is right. But we can't have everything. Our tent is big, but
turned out to have small doors or too many uninvites showed up. I think
that until we have this new collimator, we should choose our battles
wisely. Are there any grad students waiting for d(gamma,pn) data?

                                                                   Vitaliy

Michael Kohl wrote:

>To throw in my coin,
>
>by requiring Cerenkov in PHYS1 trigger type, we would then suppress the
>photodisintegration channel d(gamma,pn), where the proton was supposed to
>be detected in the left sector, but no electron, and a proton doesn't
>fire the Cerenkov.
>
>Michael
>
>
>
>
>
>>Good morning:
>>
>>I must have not thought things completely through. A quick check with
>>Eugene on the phone shows that indeed CC remove all the trackless stuff
>>in trig==2 just as richard suggested.
>>We can require CC in trig==2 (e,e'n) which would yield a significant
>>reduction of that trigger. One can monitor the CC efficiency with ee'p
>>events from trig==1, which does not contribute to the deadtime as much.
>>
>>-- t
>>________________________________________________________________________________
>>Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124
>>research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949
>>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>On Fri, 5 Mar 2004, John Calarco wrote:
>>
>>
>>
>>>Hi Richard,
>>>
>>>I may be wrong, which is why I opened my comment with "Be careful." ...
>>>meaning we need to think carefully to not make any mistakes. Unless I'm
>>>wrong (which may be the case), PHYS0 contains the elastic as well as
>>>quasielastic e,e'p. Thus a simple hardware AND of the CC takes the
>>>last 4 TOFs out of the trigger which means we get no triggers for
>>>elastic events in the last 4 TOFs, the high Q^2 region. It is possible
>>>of course to work around this and have a hardware trigger of (any TOF
>>>AND CC) OR (last 4 TOFs). This keeps the last 4 TOFs in the trigger,
>>>but now I begin to worry about timing. For every logical operation,
>>>we accumulate a delay of at least 10 ns in the trigger. If the 2
>>>Boolean operations I just described have to be done sequentially, then
>>>we have at least 20 ns delay in the trigger relative to the retiming
>>>signal. At some point we run into trouble. Perhaps Karen or others
>>>might wish to comment.
>>>
>>>So, to reiterate, "Be careful." Any change in the trigger is possible
>>>but MAY (repeat, MAY) have possible unforeseen consequences which have
>>>to be assessed before making the change.
>>>
>>>
>>>On Thu, 4 Mar 2004, Richard Milner wrote:
>>>
>>>
>>>
>>>>I am not sure what you mean John. The idea is that where we have Cerenkov
>>>>detectors in the acceptance we should seriously consider to use them in
>>>>the electron trigger. They are now highly efficient and should
>>>>reduce trackless triggers, e.g. in (e,e'n) as a means to reduce the
>>>>deadtime.
>>>>
>>>>Elastic scattering on both the deuteron and proton has the benefit of
>>>>being completely kinematically correlated. My understanding is that this
>>>>trigger type is a relatively small contributor to the deadtime.
>>>>
>>>>Also, for the proton target we have only the (e,e'p) assuming we prescale
>>>>the inclusive.
>>>>
>>>>Am I missing something?
>>>>
>>>>Richard
>>>>
>>>>On Thu, 4 Mar 2004, John Calarco wrote:
>>>>
>>>>
>>>>
>>>>>Be careful. Now that we have removed CC3 from behind the 4 rearmost TOFs
>>>>>and put them behind the BATs, a hardware CC requirement restricts the
>>>>>high Q^2 end, and that's where the ed elastic T20 overlaps the very
>>>>>interesting region where the old Bates data overlap the recent JLab
>>>>>data. I don't think we want to sacrifice that, and I definitely want
>>>>>the high Q^2 end for the ep elastic.
>>>>>
>>>>>
>>>>>On Thu, 4 Mar 2004, Karen Dow wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Just spoke with Richard on the phone, he requested that someone check how
>>>>>>much a hardware Cerenkov requirement would cut the trigger rate, hoping to
>>>>>>reduce the rate of PHYS1 significantly (and possibly also PHYS0). Tavi and
>>>>>>Baris will look at crunched data while they're on shift, see what a
>>>>>>Cerenkov cut does to the number of trig==2 and trig==1, also what it does
>>>>>>to the spectra (z, momentum, theta etc -- presumably we don't lose good
>>>>>>events).
>>>>>>
>>>>>>Karen
>>>>>>
>>>>>>
>>>>>>At 01:42 PM 3/4/2004 -0500, Richard Milner wrote:
>>>>>>
>>>>>>
>>>>>>>Following Tancredi's mail, I think we should significantly prescale the
>>>>>>>inclusive and put more lead shielding in front of the forward LADS. Ernie
>>>>>>>is working up a modification of the collimator which has the potential to
>>>>>>>improve the deadtime situation for the inclusive trigger. Until we can
>>>>>>>implement that, we should optimize running conditions for (e,e'd), (e,e'p)
>>>>>>>and (e,e'n) both vector and tensor.
>>>>>>>Richard
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>On Thu, 4 Mar 2004, Tancredi Botto wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>A brief summary of the present understanding of deadtime sources from the
>>>>>>>>analysis of recent data:
>>>>>>>>
>>>>>>>>Deadtime is limiting us in the use of higher beam currents. There are many
>>>>>>>>components to this: the most significant is "trackless" triggers that pass
>>>>>>>>the 2nd level trigger thanks to random hits in the wch. The ratio of
>>>>>>>>these fake 2ndl level triggers (abot 2/3 of total data) is consistent with
>>>>>>>>the Wch S/N ratios. The ratio of trackless triggers is nearly independent
>>>>>>>>of trigger type.
>>>>>>>>
>>>>>>>>Trackless triggers have no known vertex or momentum distribution of course
>>>>>>>>but they contribute fully to DAQ deadtime. They are very sensitive to Wch
>>>>>>>>multiplicity and S/N. Possibly this is related also to the collimator
>>>>>>>>
>>>>>>>>
>>>>>>>design.
>>>>>>>
>>>>>>>
>>>>>>>>Trackless events really have too few wch hits (often < 3 hits in the tdc
>>>>>>>>range used in the reconstruction of the wch events). We can't use a
>>>>>>>>momentum cut to truly speak about deadtime..
>>>>>>>>
>>>>>>>>A second contribution is coming from low-momentum particles that originate
>>>>>>>>mostly upstream of the target. These events constitute the vast majority
>>>>>>>>of "tracked" triggers, but a smaller fraction of the overall yield. They
>>>>>>>>are well characterized in momentum (100-200 MeV/c), charge (positrons for
>>>>>>>>inbending field, electrons for outbedending - both fire the Cerenkovs) and
>>>>>>>>location in the detector (tof #'s 10-14).
>>>>>>>>
>>>>>>>>These events must originate from 300 MeV photons in a EM shower. The
>>>>>>>>
>>>>>>>>
>>>>>>>shower
>>>>>>>
>>>>>>>
>>>>>>>>having photons (which are not "bent") may contribute again to the Wch S/N.
>>>>>>>>Note that trackless triggers are instead *uniformly* distributed in the
>>>>>>>>
>>>>>>>>
>>>>>>>TOF's
>>>>>>>
>>>>>>>
>>>>>>>>We have never experienced such a harsh environment before because we were
>>>>>>>>not running with an inclusive trigger (requires a cerenkov) prescaled by 6
>>>>>>>>and because we did not add the LADS to the e,e'n trigger. Having done so
>>>>>>>>it offers many more opportunities for trackless and low-energy-background
>>>>>>>>triggers. Indeed trig==2 and trig==7 are the dominant distribution of
>>>>>>>>trigger types.
>>>>>>>>
>>>>>>>>To make matters worse, any of these trigger rates will show a dependence
>>>>>>>>on beam current and as mentioned in the prev email it is important to
>>>>>>>>operate in a linear region. Regards,
>>>>>>>>
>>>>>>>>
>>>>>>>>-- tancredi
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>________________________________________________________________________________
>>>>>>>
>>>>>>>
>>>>>>>>Tancredi Botto, phone: +1-617-253-9204 mobile:
>>>>>>>>
>>>>>>>>
>>>>>>>+1-978-490-4124
>>>>>>>
>>>>>>>
>>>>>>>>research scientist MIT/Bates, 21 Manning Av Middleton MA,
>>>>>>>>
>>>>>>>>
>>>>>>>01949
>>>>>>>
>>>>>>>
>>>>>>>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>--
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:30 EST