From G.F.Pearce@rl.ac.uk Tue Feb 11 10:13:34 2003 Status: RO X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil] ["6305" "Tuesday" "11" "February" "2003" "15:13:03" "-0000" "Pearce, GF (Geoff) " "G.F.Pearce@rl.ac.uk" "" "150" "RE: FarDet trigger." "^From:" nil nil "2" nil "FarDet trigger." nil nil nil nil nil nil] nil) Received: from smtpgw3.sec.bnl.local ([192.168.1.47] helo=smtpgw3.bnl.gov) by minos with esmtp (Exim 3.34 #1 (Debian)) id 18ic6I-0007H4-00 for ; Tue, 11 Feb 2003 10:13:34 -0500 Received: from bnl.gov ([130.199.128.163]) by smtpgw3.bnl.gov with esmtp (Exim 3.36 #1 ) id 18ic6K-00007f-00 for ; Tue, 11 Feb 2003 10:13:36 -0500 Received: (from daemon@localhost) by bnl.gov (8.12.4/8.9.2) id h1BFDVJB003590 for bviren@minos.phy.bnl.gov; Tue, 11 Feb 2003 10:13:31 -0500 (EST) Received: from smtpgw1.bnl.gov ([192.168.1.45]) by bnl.gov (8.12.4/8.9.2) with ESMTP id h1BFDTIV003579 for ; Tue, 11 Feb 2003 10:13:29 -0500 (EST) Received: from exchange01.rl.ac.uk ([130.246.135.134]) by smtpgw1.bnl.gov with esmtp (Exim 3.36 #1 ) id 18ic5y-0000wB-00 for ; Tue, 11 Feb 2003 10:13:14 -0500 Received: by exchange01.rl.ac.uk with Internet Mail Service (5.5.2656.59) id <1HMV75M0>; Tue, 11 Feb 2003 15:13:05 -0000 Message-ID: From: "Pearce, GF (Geoff) " To: "'Brett Viren'" Cc: "Pearce, GF (Geoff) " Date: Tue, 11 Feb 2003 15:13:03 -0000 Subject: RE: FarDet trigger. X-PH: V4.4@bnl.gov X-Mailer: Internet Mail Service (5.5.2656.59) X-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 X-Spam-Level: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Brett, Sorry I don't have this on the web. I really should have so I'll make this the seed for generating a page. The triggering in the DAQ is intentionally made inclusive, in as much as that is possible rate wise. Pulse height is not used at all outside of the electronics. The assumption is made that we want as loose a trigger as possible and that the offline event selection on the snarls will make a tighter selection - channel dependent no doubt. There are two parts to the answer: a. how does the electronics 'trigger' a hit (dynode thresholds, sparsification thresholds, VARC trigger) b. how does the DAQ form a trigger from collections of hits. Hits. ==== Critical to the triggering and the reconstruction, particularly for NuE I would guess, is what constitutes a hit. This is defined in the electronics. We are meant to run "triggerless", meaning each PMT self triggers with it's dynode signal. It's one of the big advantages of our system, but as you know the scintillator readout fibers are generating their own light and pushed the singles rate up by ~ x10. It also put the chip dead time rate up in the same way, so the decision was to put local triggering in the FEE (the VARC 2/36 trigger) as this solved both problems (the DAQ could be made to handle the rate but could do nothing about the chip dead time). So, what is a hit: 1. The PMT dynode signal must be above threshold. The thresholds should be individually set to 1/3 p.e. but this tuning has yet to be done at Soudan. They are using the same DAC threshold value throughout at the moment I believe, so the threshold will be different for each PMT in terms of pe's. In the design system, this is the only trigger there is. 2. Each VARC can serve up to 36 chips (12 VFBs, 3 VA chips each). Each chip is one PMT of course. The VARC trigger requires that at least 2 of the chips on the VARC satisfy the above dynode trigger before the VA chips digitise. If there really are 36 chips connected to the VARC, this is a 2/36 local trigger. In fact, many VARCs do not have this many chips connected so for them it is a 2/N local trigger, where N<36. Yes, this can lose single hits at VARC boundaries - you have to be careful of this. 3. Shield PMTs are excluded from the VARC trigger. They need only satisfy 1. 4. If the trigger is satisfied, all 16 channels on the triggering chips are digitised and read out, subject to the sparsification threshold, i.e. zero suppression. The sparsification thresholds need to be fine tuned at Soudan also, and should be set at about 3 pedestal widths above pedestal. The scintillator rates have been slowly dropping so it is possible that one day we may be able to drop the VARC trigger or reduce it to a 2/6. We (sergei in particular) are watching this but nobody is holding their breath. Snarls ====== Now the DAQ trigger. The DAQ is using the "gap" method at Soudan to identify a "candidate snarl" based purely on timing information and then applies a trigger test to that candidate. The procedure is 1. Time order all the detector hits. Scans through the hits are always done in time order. 2. Starting with the first hit, scan through the hits until the time difference between neighbouring hits is larger than T. Let's say this happens on hit n, then (T - T) > T. This defines the candidate snarl, i.e. hits 1 to n inclusive. A value for T of 100 clock ticks is being used, the same as at CalDet (1 VA clock tick is the usual 25/16 ns). 3. Using all of the hits in the candidate (1 to n) test to see if M planes in any consecutive N planes have at least one hit in them. Any hit, regardless of pulse height, qualifies. M and N are 4 and 5 respectively, i.e. 4 out of 5 plane trigger. 4. That's it. If it triggers, write it out. If not, dump it. Then start again at hit (n+1) This is an inclusive trigger aimed at minimum bias. An offline selection should cut the rate down considerably. In addition to the plane trigger, I introduced an "activity" trigger for development testing at one point which was 'OR'd with the plane trigger. This required that the candidate snarl had hits in ANY N planes. I intended to extend this to trigger on energy deposited as well, though that has issues of calibration to negotiate. We are not running with the activity trigger. It was removed from the trigger mask because of the Light Injection echoes that the electronics is producing - it was very efficient at picking up the echoes! This was part of the raison d'etre, to identify correllated detector noise, so I guess it was successful. The second method the DAQ can apply is NOT being used at Soudan although there are a number of reasons why we might want to switch back to it. The "gap" method was strongly favoured at the CalDet which is why we have been using it as the default at Soudan. The second method is the sliding window. 1. Hits are time ordered as above 2. Step through the hits one at a time. Let's say we are starting at hit n for the sake of this example. If the time of this hit is T, collect all the detector hits that fall in the time window T to T + dT. I tuned dT to 50ns using MC (a long time ago) but of course it could be anything. 3. Test these hits to see if they satisfy the M out of N plane trigger. 4. If they do not satisfy the trigger, step forward one hit and start again. i.e. go back to 2. and use hit (n+1) as the start hit. 5. If they do satisfy the trigger, define the snarl to be all hits in the fixed time window T to (T + dT). The readout window size can be anything, typically ~ 200ns. Then go back to 2. and start again with the first hit AFTER the snarl. Hope this is clear. Geoff -----Original Message----- From: Brett Viren [mailto:bv@bnl.gov] Sent: 10 February 2003 16:42 To: Geoff Pearce Subject: FarDet trigger. Hi Geoff, I want to check that the FarDet trigger is correctly implemented in the current GMINOS with an eye on seeing how the current 4/5 setting effects nu_e searches. Can you point me to details on exactly how the trigger is implemented? For example, what is the PE threshold for a plane to be considered "hit"? How is that added up from individual digits? How is the 4/5 selection implemented? Thanks, -Brett. From G.F.Pearce@rl.ac.uk Tue Feb 11 12:21:48 2003 Status: RO X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil] ["2443" "Tuesday" "11" "February" "2003" "17:21:28" "-0000" "Pearce, GF (Geoff) " "G.F.Pearce@rl.ac.uk" "" "62" "RE: FarDet trigger." "^From:" nil nil "2" nil "FarDet trigger." nil nil nil nil nil nil] nil) Received: from smtpgw2.sec.bnl.local ([192.168.1.46] helo=smtpgw2.bnl.gov) by minos with esmtp (Exim 3.34 #1 (Debian)) id 18ie6O-0007bM-00 for ; Tue, 11 Feb 2003 12:21:48 -0500 Received: from bnl.gov ([130.199.128.163]) by smtpgw2.bnl.gov with esmtp (Exim 3.36 #1 ) id 18ie6I-0002be-00 for ; Tue, 11 Feb 2003 12:21:42 -0500 Received: (from daemon@localhost) by bnl.gov (8.12.4/8.9.2) id h1BHLgE1014563 for bviren@minos.phy.bnl.gov; Tue, 11 Feb 2003 12:21:42 -0500 (EST) Received: from smtpgw2.bnl.gov ([192.168.1.46]) by bnl.gov (8.12.4/8.9.2) with ESMTP id h1BHLgIV014559 for ; Tue, 11 Feb 2003 12:21:42 -0500 (EST) Received: from exchange07.rl.ac.uk ([130.246.135.148]) by smtpgw2.bnl.gov with esmtp (Exim 3.36 #1 ) id 18ie6F-0002Zc-00 for ; Tue, 11 Feb 2003 12:21:39 -0500 Received: by exchange07.rl.ac.uk with Internet Mail Service (5.5.2656.59) id <1JPGT3VS>; Tue, 11 Feb 2003 17:21:36 -0000 Message-ID: From: "Pearce, GF (Geoff) " To: "'Brett Viren'" Cc: "Pearce, GF (Geoff) " Date: Tue, 11 Feb 2003 17:21:28 -0000 Subject: RE: FarDet trigger. X-PH: V4.4@bnl.gov X-Mailer: Internet Mail Service (5.5.2656.59) X-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Brett, 1) Do VARC boundaries ever slice a plane? That is, are there any planes that are read out by more than one VARC? =========== No, the VARC boundary should never disect a plane. A single VFB (MUX box if you like) serves one side of readout from two planes. There are 3 chips on the VFB (16 channels used on each, a plane needs 24). Two of the 3 chips are dedicated to individual planes; the third chip is shared between planes (8 channels each). In short, the unit is exactly two planes go to a single VFB and two VFBs go to a single VMM on the VARC, so they don't cross VARCs. This is not to say nobody could do it! =========== 2) Given a 2/N local trigger in some VARC, are all other VARC's read out, regardless of their local trigger status? ========== No. Only the chips that triggered are read out. All this is doing is tightening the dynode triggering a little by demanding at least one other PMT on the VARC was above threshold to get the rate down. This can be done easily in the VARC firmware since it initiates the VA digitisation. The VARCs don't talk to one another. ========== I am guessing both answers are "no". If so, then at worse an event will loose one hit (err. "digit"), correct? =========== Yes, probably. It must depend on what the events look like. Andrei did a MC study of this about a year ago. He presented the results at a Minos meeting so his slides must be on Dave Ayres web page somewhere. ============ So, (if correct), we will loose events which have exactly 4 out of 5 hit planes with 3 hits planes read out by one VARC and 1 hit plane (with one hit PMT) inside the neighboring VARC. It remains to be seen what loss in efficiency this translates to. ============ Sounds right. I'd look to a simulation though! There is also an effect on the energy measurement of events that do trigger. ============ BTW, ignoring this VARC boundary issue, I applied a simple 4/5 plane trigger to the MC, with a hit plane being defined as having at least one reconstructed "CandStripSR". I find that 1.5% of beam nu_e CC QE events are lost. ============== That doesn't sound too bad. Are the thresholds used in the MC realistic? When I did a study of this for the TDR I found 0.5% of neutrino events failed the trigger; these were all NC events - I didn't look at nu_e specifically. Also, it was with the high energy beam, the vogue in those days, which would be less sensitive. =============== Geoff From G.F.Pearce@rl.ac.uk Mon Feb 17 13:48:12 2003 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1956" "Monday" "17" "February" "2003" "18:48:07" "-0000" "Pearce, GF (Geoff) " "G.F.Pearce@rl.ac.uk" nil "53" "RE: FarDet trigger." "^From:" nil nil "2" nil "FarDet trigger." nil nil nil nil nil nil] nil) Received: from smtpgw3.sec.bnl.local ([192.168.1.47] helo=smtpgw3.bnl.gov) by minos with esmtp (Exim 3.34 #1 (Debian)) id 18kqJI-00034X-00 for ; Mon, 17 Feb 2003 13:48:12 -0500 Received: from exchange07.rl.ac.uk ([130.246.135.148]) by smtpgw3.bnl.gov with esmtp (Exim 3.36 #1 ) id 18kqJG-0003ZX-00 for ; Mon, 17 Feb 2003 13:48:10 -0500 Received: by exchange07.rl.ac.uk with Internet Mail Service (5.5.2656.59) id <1JPGTY43>; Mon, 17 Feb 2003 18:48:08 -0000 Message-ID: From: "Pearce, GF (Geoff) " To: 'Brett Viren' Cc: "Pearce, GF (Geoff) " Date: Mon, 17 Feb 2003 18:48:07 -0000 Subject: RE: FarDet trigger. X-Mailer: Internet Mail Service (5.5.2656.59) X-MailScanner: Found to be clean X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 X-Spam-Level: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Brett, Not so easy! To first order the following applies. There are 3 VARCs in each crate (0,1,2). Varc 1 is full of "detector plane" VFBs and VARCs 0 and 2 have 10 out of their 12 VFB slots connected to planes. The remainder are either shield readout or the LI pmt (TPMT), both of which are excluded from the VARC triggering. (So, for example, Varc0 of Crate 0 is a 2/30. Remember, each VFB = 1 MUX box = 3 PMTs) This is only to 1st order because the last two crates of SM1 do not get filled so well. There aren't enough planes, so they "mop up" what is left. The last 2 planes of SM2 do work out pretty well; because SM1 was filled to capacity, there are fewer planes in SM2 (the total is constant) and the last 2 crates rather neatly fill up 2 VARCs each. Look at the DAQ map: http://www-numi.fnal.gov/minwork/daq/fardet/cabling-map.html All those slots that are white background with plane numbers written on them are in a "2/N" VARC trigger. The rest (TPMT (red), SHLD (green) or unused (black)) are NOT. Since you are running offline jobs, you can get the accurate mappings directly into your MC from the Plex. NB Shield installation is ongoing so many of those marked unused (black) will read out shield as it is installed. Geoff -----Original Message----- From: Brett Viren [mailto:bv@bnl.gov] Sent: 13 February 2003 20:19 To: Pearce, GF (Geoff) Subject: RE: FarDet trigger. Hi Geoff. I hope you will indulge another question: You mention that the 2/"36" local trigger is not always 2/36 because some VARCs are not fully instrumented with PMTs. Can you give me an idea of the distribution of VARC PMT occupancy? Is it just VARCs at the end of each super-module which are not full? So far a pure 2/36 + 4/5 plane trigger seems to be okay for both trigger efficiency and energy for nu_e CC QE events, but if the "36" is significantly lower over much of the detector the small effect that I do see will, of course, increase. -Brett.