1 / 4

B-Physics Trigger in the TDR

B-Physics Trigger in the TDR. Demonstrate viable & affordable B-physics trigger based on the evaluation of two strategies: 1) Di-muon trigger at L=2x10 33 , introducing full scan at lower luminosity 2) RoI guided B-trigger, possibly with addition of full-scan at lower luminosity

derek-cohen
Download Presentation

B-Physics Trigger in the TDR

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. B-Physics Trigger in the TDR • Demonstrate viable & affordable B-physics trigger based on the evaluation of two strategies: • 1) Di-muon trigger at L=2x1033, introducing full scan at lower luminosity • 2) RoI guided B-trigger, possibly with addition of full-scan at lower luminosity • Define 2 as baseline???? • To do this need measurements of: • Efficiency for signal channels • Rate • c.p.u resource estimate based on test-bed measurements for whole chain.

  2. Status of di-muon & full-scan triggers 1) Di-muon trigger at L=2x10^33, introducing full scan at lower luminosity • Current Status: • Full-scan based strategy studied in detail using fully-simulated events and appropriate LVL2 and EF algorithms and documented in TP back-up document: ATL-DAQ-2000-031 • Robustness of selection w.r.t. ID misalignment studied & documented in: ATL-DAQ-2001-006 • EF selections documented: • Rejection of rate at EF for J/Y, Ds and B0d->pp channels. (Moscow) ATL-DAQ-2000-017 • Event Filter Rate for the Ds Trigger (Innsbruck) ATL-DAQ-2001-003 • Impact of only having 2 pixel layers at start-up studied using IDscan LVL2 algorithm • Estimates exist for LVL1 di-muon rates and EF rates after J/Y(m,m) and B->mmX trigger selections • Required c.p.u. resources have been estimated based on measured rates and executions times and documented in: ATL-COM-DAQ-2002-013 • Algorithms : • LVL2: mFast (barrel only), Pixel-scan+sctKalman, IDscan, TRT-LUT, xKalmanTRT • EF: xKalman, muon-? (for resource calculations assume mFast re-run at EF)

  3. Benchmarking & Resource Estimates Preliminary paper model results (April 2002): Final Farm size Difference ~25 c.p.u Min. size incl. B-physics Min. Farm size needed at startup LVL2 • Note: • Based on custom-LVL2 algorithms, light-weight EDM, excludes data access overheads • Most B-trigger resources required for LVL2 full-scan • In order to save cpu resources, estimate does not include TRT at LVL2: • => No J/psi(e,e) trigger • EF • Resources required at EF small compared with LVL2 (~few cpu) assuming: • xKalman starting with pixels and guided by Level-2 RoI • neglecting resources needed for muon reconstruction at EF • Current offline muon algorithms too costly in cpu : • => Only includes muons at LVL2 reconstructed by mFast B-trigger resource estimate: ATL-COM-DAQ-2002-013

  4. Using Calorimeter RoI to guide B-physics Triggers • Preliminary studies of using low ET RoI to define regions to search ID at LVL2(Alan Watson) • Uses fast simulation : • ATLFAST + parameterised calorimeter simulation • Initial results encouraging,see Alan Watson’s talk:http://www.ep.ph.bham.ac.uk/user/atw/bmeet/B-roi-feb02.ppt • EM RoI ET>2 :for J/y(ee) and muon-electron triggers • Mean Multiplicity = 1.1 (B->mX , m pT > 6 GeV) • Effic. to tag both e in J/y(e,e) : 80% (e pT >3 GeV) • Jet RoI (0.8 x 0.8 cluster) ET>5 :for B(pp) and Ds(fp) • Mean Multiplicity = 1.7 (B->mX, m pT > 6 GeV) • Efficiency • B p p • pTp> 4 GeV • RoI ET> 5 GeV • B Dsf • pT Ds, f> 1 GeV • RoI ET> 5 GeV • LVL2 reconstruction inside RoI • potential to save ~factor 10 in execution time c.f. full-scan • but with lower efficiency Actual efficiencies and cpu savings depend on thresholds & multiplicities => need full simulation

More Related