Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Det. Search
Who's who?
Intern. region
Vertex Tracker
Drift chamber
Run Coordination
Contact Experts
Shift Takers Info
Operations Manual
Electronic Logbook
Ops Hypernews
Shift Signup
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

Trigger configuration meetings

This page is intended as some kind of record of the discussions taking place of the proposals for tightened trigger configurations. Please make corrections as neccessary!

Minutes of the configuration meeting (Nov 28, 2006)

Attendees: Debbie Bard, Rainer Bartoldus, Al Eisner, Fang Fang, Selina Li, Su Dong, Mark Tibbetts. meeting files

Long-term configuration change (stage 1)

  • Addition of 1Zn(1Zk) object to lines 1,2,3 and 14, and increase of supression of prescale lines investigated by Su Dong, and effect on rates here. Adding 1Zn line gains 19%, adding the increased prescales on top of that takes it to 26% rate reduction.
  • Rainer ran before (stage 0) and after (stage 2) trigger emulators for these changes. The results are in here.
  • Prescales lines are about 20% of rate, and could be sacrificed in favour of physics. However, concerns about cutting prescale lines:
    • Diagnostics - can combine several runs to get statistics back so more supression won't affect this too bad. Cutting a pre-scale line altogether would be bad!
    • What analyses rely on prescaled lines for physics? Not B physics, but ISR and tau analyses may do. Need updated statistics survey on Run 5 to check.
    • How to scale prescales? Set a total budget and scale lines according to physcis worth? How to evaluate 'worth'? Who uses these lines anyway?
  • 1Zn(1Zk) line needs to be validated, it's still somewhat contoversial (but needed!).
    • Definition: 800 MeV Pt cut on one side, 250 MeV on other. Z cut of 15cm.
    • Should do some kind of analysis with charge-dependent cuts and check output.
  • Things to do:
    • Try this again on the up-to-date Run 5 configuration, which has no 1M and a higher 1Z prescale.
    • Should fix the non-prescaled changes first, then look at what needs to be done from the prescaled lines.

Emergency configuration change

  • On top of the stage 1 changes, Su Dong killed lines 3, 9 and 11 completely, added a 2M on line 14 and further increased some prescales. Effect on rates here.
  • Killing lines is an easy way to kill rate, but what physics do we lose with that?
    • Killing lines which appear to have no exclusive events in the trigger studies makes sense, but that gains ~3%.
    • Getting rid of 3M+M* is possibly a bad idea, but if we kill 3M+D2+1Z alone it picks up a lot of what previously went through 3M+M* - one is a sub-set of the other, effectively. ->Correlations between trigger lines are an issue!
  • Prescale can be sacrifced in an emergency, which will gain 22% on trigger rate if we kill them totally. (Combined with 1Zn(1Zk) object, that's ~35%, which is good). BUT! If we lose all prescales for runs with high backgrounds, how do we calculate trigger efficiency for those runs? Presclae lines are a buffer, at least.
  • Other issue with short-term configuration changes: if it's in place for less than a month, at present it will not be simulated as the simulation takes monthly configuration samples. This is not unfixable...
  • Things to do:
    • Explore how much difference 1M -> 2M makes, and if adding 1M in places would help.
    • Kill lines one at a time to see which single one has the largest effect.
    • Kill 3M+Dz alone and see which next worse line is - what could be killed in combination with this to make up for the 3M+M* that we probably want to keep?
    • Check effects of prescale line removal on physics events. Especially non-B physics events!
    • The emulator cannot model changes in prescale factors, so concentrate on getting 1Zn(1Zk) in there. We can estimate prescale effects as they're orthogonal.
Update: 29th Nov. Rainer confirms effect from killed trigger lines alone.

Meeting 30th Nov

meeting files

Long-term configuration change

  • Comparing runs 50577 and 67676, in 2 years, the trigger rate hasn't changed much, even with a 25% increase in lumi! This is encouraging.
  • Adding 1Zk on the 4 propsed lines has a 19% reduction in trigger rate.
    • Need to check what effect his has on B physics! For this, need to get MC.
    • Is any Acp itroduced with the 1Zk?
    • What effect does this addition have line by line?
  • The prescales need ot be examined one by one, to see if anyone uses them and if we can remove any/increase prescale, with no effect on analyses.
    • For Run 6 start-up config, 3M will be replaced by 1Zk observer line.
    • Can we remove 3B+2A?

Emergency configuration change

  • What effect will 1Zk have, after lines have been killed and prescales increased?
    • From Su Dongs studies from ZPD diagnostics, it seems that 1Zk gives an improvement of ~9% on Rainer's 'Emergency 2b' emulated configuration (not that Su Dong's plot has the 2Zt+1A+2M+1Zk while Rainer uses 1M).
  • Can we get pure EMT without the 3M+M* in B physics? What do we get with this that is not caught by 4M? This should be looked at before we decide to remove 3M+M*.

Things to do:

  • For long-term (tight) config change need MC simulation with 1Zk to really check if it's safe or not for physics.
  • Need to relate rate reductions to dead-time effects.
  • Is any Acp introduced by adding the 1Zk? Need a tool to compare 1Zk with Z'.
  • Should complement B studies with B->nunu, dileptons and B recos with Run 5 config. Should check BGFilter with these.
  • Add 1Zk line-by-line to check effect of 1Zk on each. This will be pretty correlated!

Meeting 4th December.

meeting files

Tight (long-term?) configuration

  • Cannot emulate 1Zk for data, but Su Dong can run ZPD diagnostics to show effect. Need to prove (on MC) that emulator and ZPD diagnostics give same results, then can trust the data results.
  • No compelling case to keep 3M/4 (see Al's hypernews posting).
  • Can take 1Z to 1024.
  • M*+1Z could be more scaled (to /8).
  • Need to look into 3B+2A some more (see Al's hypernews posting).
  • Others can be killed. This will gain us up to 5% from prescales alone.

Emergency configuration

  • Here are some trigger rate plots for run 67676 (Aug06 config) for various emergency levels (culmative, but reductions are absolute):
    • Emergency 0: As Aug2006, but with pure FCT lines not passed (~0.7% reduction).
    • Emergency 1: kill most prescaled line back to 1024 (~8% reduction).
    • Emergency 2: kill 4 lines and add 2M (~16% reduction).
    • Emergency 3: kill 3M+M* as well (~25% reduction).
    • ->Gives a max reduction of 25%, so will still need 10-15% from 1Zk, which can now be applied to only 2 lines.
  • Can we make a separate 'GoodRuns' list that only contains emergency runs? Some analyses won't want to include these.
  • SP-7254 plots here are generic taus (no fiducial cut applied), SP-3429 are B->nunu, showing effect with emergency-3 trigger. These should be compared to Emergency-0 level, but effects look ~small. What will this actually mean for their physics though?
  • Emergency 4 - as Em. 3 + 1Zk. This will be run for validation on B->nunu and generic taus, to start with, also di-lepton events.

Meeting 12th December.

  • Rainer's Zk configuration specs were discussed, as per his hypernews posting. Bit 4 is Zk. The energy cut is 800MeV (+ve track) and 200MeV (-ve track), z0 cut +/- 12cm, n missing layers in DCH allowed = up to 10.
    • z0 can be studied in L1TNtuple ZPD data, but we're unlikely to want to make it looser than the +/- 12cm cut on the 1Z lines.
    • What does Z0ErrMax do?
  • 1Zk will replace D2*+1M line, Zt will replace 3M line for default Run 6 configuration. The order of prescaled lines will be: 3B+2A, M*+1Z, 1Zk, 1Zt, 1Z. The Z lines will be prescaled to 512.

This page is created by Debbie Bard (; however, you are welcome to edit and/or correct above items, specially for those who attended the meeting. Thanks.