1 / 17

ATLAS Data Challenges The Physics point of view

ATLAS Data Challenges The Physics point of view. UCL, September 5th 2001 Fabiola Gianotti (CERN). Three data challenges are foreseen: -- DC0 : end 2001 -- DC1 : first half 2002 -- DC2 : first half 2003  Computing TDR

kameko-mack
Download Presentation

ATLAS Data Challenges The Physics point of view

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. ATLAS Data ChallengesThe Physics point of view UCL, September 5th 2001 Fabiola Gianotti (CERN)

  2. Three data challenges are foreseen: -- DC0 : end 2001 -- DC1 : first half 2002 -- DC2 : first half 2003 Computing TDR • Goals : validate our computing model and our software Important physics content : provide data samples for physics studies and hopefully many physics results • How ? • Start with data which looks like real data  need MC generators, G3/G4 simulation, event model, detailed detector response (e.g. noise, cross-talk, etc.), pile-up • Run the filtering/trigger and reconstruction chain • Store the output data into the database • Run the analysis • Produce physics results

  3. DC0: November - December 2001 • In principle should be a test of the WHOLE software chain : a kind of “rehearsal” for DC1 (check that everything works for DC1) • Issue is therefore not massive production of huge data samples but few 100k events able to test the whole software chain • Chosen physics sample : few 100 k Z+jet events, with Z  . -- allows tests of ALL sub-detectors (including b-tagging since 6% of jets are b-jets) -- idea is to produced several samples with the 3 general-purpose generators (PYTHIA, Isajet, Herwig) • If you want to participate in DC1, you are (strongly) encouraged to participate in DC0 as well.

  4. DC1: February - July 2002 • Scope : stress-test the system with large-scale production, reconstruction and analysis • Several samples of up to 107 events   10% data collected at LHC in one year. • Crucial issues : -- simulation will be done mainly with G3but it is important to perform smaller-scale production with G4 -- comparison G3/G4 (with same geometry, to be meaningful …) -- learn about event model and detector description -- I/O performances : N events with different technologies -- pile-up treatment -- understand bottle necks -- understand distributed computing model / GRID (not discussed here)

  5. DC1: Physics samples • 107 jets for e/jet separation studies in view of Trigger/DAQ TDR (due end of 2002). ~ 10 times more statistics than “old jet production”. Study performance of ATHENA and HLT algorithms. Useful also for other physics studies (e.g. optimisation of jet energy reconstruction algorithm) • Any other CPU-consuming physics sample considered useful for physics studies.Mainly SM “background processes” : examples: -- inclusive muon sample (for B-physics and muon performance studies), Zbb and Wbb samples (backgrounds to many searches), WW/ZZ samples -- Z   for tau-lifetime studies -- several samples with different generators to understand the physics of various MC • Physics groups and Combined Performance groups asked to prepare list of wishes  first discussions at Physics Coordination in Lund and at October ATLAS week. Everybody is encouraged to make suggestions

  6. DC2 : January - September 2003 • Scope/precise goals: depend on the outcomes of DC0/1 • Present goals: -- 108 events ( data collected in 1 LHC year) -- Geant4 should play a major role -- full test of calibration/alignement procedures and condition database -- question : do we want to add part or all of DAQ, LVl1, LVL2, Event filter ? • Physics content: -- demonstrate capability of extracting and interpreting a signal from New Physics -- generate various SM samples and “hide” in each one a different New Physics process (e.g. SUSY for one mSUGRA point, excited leptons, etc.). -- people will be asked to understand the nature and all possible features of the signal (without knowing a priori what it is)

  7. Number of events Time hours SI95 Total size DC0 ~ 105 ~105 ~ 0.2 TB DC1 ~ 107 ~107 ~ 20 TB DC2 ~ 108 ~108 ~ 200 TB DC production : CPU and data size

  8. “Physics readiness document” (kind of Physics TDR prime … ) : LHC t0-1year Content (examples): • Work done with MC generators, the ATLAS MC library, status/strategy for MC production • Strategy for using different levels of simulation (full, parametrisations, fast) for different processes • Comparisons G4/test-beam data, FLUKA/test beam-data  systematics from full simulation • Main figures of Physics TDR redone with new/final software • Specialised packages needed for various physics studies (e.g. MSSM scan packages for Higgs and SUSY with up-to-date theoretical calculations, etc.) • etc.

  9. Status of the non-core software(my view, emphasis on “physics part”) • Main generators(PYTHIA, ISAJET, HERWIG) interfaced to HepMC (HERWIG being finalised …). Next : specialised generators (e.g. VECBOS, QQ) • Simulation : -- G4 : physics validation not completed (lot of work done with EM physics, hadronic physics being tested now); full ATLAS geometry not yet in. -- DC0, DC1: use G3 plus smaller/restricted (e.g. to some detector parts) productions with G4 -- FLUKA : I am 100% sure with need it. I intitiated a pilot-project with Tilecal : G4 test-beam geometry input to FLUKA (first results in Lund). Then extend to other sub-detectors • Intermediate simulation (e.g. shower/track parametrisation): I am 100% sure we need it. Tried to find people over the last two years  failed. Recently a couple of groups have shown some interest.

  10. ATLFAST OO (UK product): -- runs in ATHENA -- reads HepMC from Objectivity, writes output into Objectivity (and ntuples) -- first validation made. Further results in Lund (from “users-non- developers”) -- next steps: improve functionality (beyond ATLFAST fortran). E.g. : shower shapes ? Trigger simulation ? Parametrisation for B-physics ? • C++/OO reconstruction: -- runs in ATHENA -- reads G3 hits/digis (Phyiscs TDR data) -- validation results in Lund • Less clear situation (to me ...) for : e.g. -- event data model -- detector description -- database , condition database, technology choice -- simulation framework vs ATHENA -- analysis tools (maybe premature today but one of the aims of DC’s should be validation of analysis tools)

  11. Where could you contribute ? Lot of work to be done everywhere , of course …. Examples: • Improve understanding of ATLAS potential for physics (e.g. SUSY, Extra-dimensions, backgrounds) and detector performance (e.g. can we tag charm-jets ?) by analysing data produced by DC’s. • Improve reconstruction, algorithms, etc. (e.g. HLT, E-flow algorithm for jet reconstruction using ID+CALOs) • Validation of MC generators: e.g. Which MC for which process ? For which processes do we need more calculations and/or additional/specialised MC ? • Validation of G4/FLUKA physics : comparisons with test-beam data (in particular nuclear interactions) • Validation of ATLFAST OO and new reconstruction against old/fortran ATLFAST and ATRECON • Intermediate simulation (shower and track parametrisations) • Detector response : hits  digi (including noise, pile-up with correct time structure, efficiency, etc.)

  12. HLT-DC1 scenario • This has to be discussed with the HLT community but the basis could be similar to what has been done previously • Generation: • Pt hard scattering > 17 Gev • | h | < 2.7 • 2 samples • 1) e-candidate • S Et > 17 Gev, no m, no n • Grid 0.12 x 0.12 • 2) Jet-candidate • S Et > 40 Gev • Grid 1.0 x 1.0 • A first selection is made at the level of the event generation • One keeps 14.5% of generated events • 14.4% for (1) and 2% for (2)

  13. HLT- DC1 scenario • Simulation • The remaining events are run through the full simulation • The Lvl1 trigger is applied at that level • One keeps 13.7% of the events • 97% for (1) and 10% for (2) • The pile-up is run for the remaining events means ~2% of the ‘generated’ sample • Reconstruction • Then the events are run through Lvl2, Event Filter and offline reconstruction

  14. What next • Prepare a first list of goals & requirements • with • HLT, Physics community • simulation, reconstruction, database communities • people working on ‘infrastructure’ activities (bookkeeping) • to be discussed • with A-team • with CSG (July 24th meeting) • In order to • prepare a list of tasks • Some Physics oriented • But also like testing code, running production, … • define the priorities

  15. Then • Start the validation of the various components in the chain (putting dead lines for readiness) • Software • Simulation, pile-up, … • Infrastructure • Database, bookkeeping, … • Estimate what it will be realistic (!) to do • For DC0 • For DC1 • “And turn the key”

  16. DC Overview Board Work Plan Definition DCExecutionBoard DC DefinitionCommittee(DC2) RTAG WP WP WP WP WP The ATLAS Data Challenges Project Structure Organisation CSG NCB Reviews ATLAS Data Challenges Reports Resource Matters DataGridProject TIERs OtherComputingGridProjects

  17. Expression of interests • So far, after the NCB meeting of July 10th: • Canada, France, Italy, Japan, Nordic Grid, Russia, Taiwan, UK • Proposition to help in DC0 • Proposition to participate to DC1 • Contact with HLT community • Contact with EU-Data-GRID • Kit of ATLAS software

More Related