Geant4 in Atlas Entering the production phase See also: A.D. talk @CHEP’01, Beijing A.Rimoldi’s talk @G4 users meeting, SLAC ‘02 C.Leggett’s talk @G4 users meeting, SLAC ‘02 A n d r e a D e l l ’ A c C E R N q u a E P / S F T d e l l a c q u @ m a i l . c e r n . c h
Atlas simulation in a nutshell � The most complicated detector ever conceived The most politicized collaboration ever gathered in HEP � � The most ambitious detector simulation program ever written � At the last count we had ~27M volumes in our G3 simulation � Need to accommodate (under the same umbrella) � Testbeam studies � Physics studies � Fast/semi-fast simulation A. Dell’Acqua – CERN EP/SFT 2 02/10/2002
The main actors � Athena � Atlas’ chosen software framework � Based on Gaudi � Provides SW environment, services, access to persistency… � GOOFY � Simulation framework � Completely based on G4 � G4Svc � Gaudi service: provides the link A. Dell’Acqua – CERN EP/SFT 3 02/10/2002
Goofy’s Design principles � Scalability Scalability � The simulation package must be able to accept � Implement some � Implement some � the simplest testbeam simulation middleware on top of middleware on top of � the complete detector simulation G4 for extending its G4 for extending its functionality functionality � Clear separation Clear separation between “core” software and user � Dynamic loading + � Dynamic loading + implementation plug-in techniques for plug-in techniques for � the “framework” connecting user’s connecting user’s � does not depend on what the users want to do code � provides maximum flexibility and freedom to the user code who wants to implement his/her own code � Action on demand to � Action on demand to � must be light avoid wasting memory avoid wasting memory A. Dell’Acqua – CERN EP/SFT 4 02/10/2002
The simulation program � has no geometry � Users build it interactively at initialization time � has no physics � Users choose from a catalog, depending on what they want to do � ..or implement their own, and add it to the catalog � has no kinematics � See above… � is an empty box A. Dell’Acqua – CERN EP/SFT 5 02/10/2002
Steps � The “standard” G4 framework is too static for our purpose: we try and get rid of it by maintaining full compatibility with G4 � no UserDetectorConstruction, no UserPhysicsList … � Provide a set of services that users can refer to � MaterialManager � DetectorFacility � PhysicsListCatalog � VisCenter… � Use the Geant4 (G)UI facilities for re-creating all connections � Make sure that users can build their their application (factorization) � Save memory Save memory , as much as one can, use proxies and lightweight objects (memory has a price, after all). A. Dell’Acqua – CERN EP/SFT 6 02/10/2002
Geometry organization � Geometry is naturally split into Detectors � A DetectorFacility class is provided for this � Users must inherit from DF and (in principle) just implement a BuildGeometry() method � There is no predefined detector organization, users build their experiment at run time � Atlas logically contains the Atlas IDET, but you can make it such that the IDET contains Atlas � Users register their detectors into a catalog by just adding one line of code (plug-in) static DetectorFacilityEntry<TileSection> calo("TileSection"); static DetectorFacilityEntry<TileSection> calo("TileSection"); A. Dell’Acqua – CERN EP/SFT 7 02/10/2002
Geometry Organization � DetectorFacilities are accessible at run time through the /control/ReadXML standard_materials.xml catalog /Geometry/GetFacility PixelDetector Pixel /control/ReadXML pixel_materials.xml /load DetectorEnvelopes /load Pixels � and define their own UI directory /load BeamPipe /TileTBeam/GetDescription TILE /Geometry/GetFacility AtlasDetector Atlas � and can be combined together in the way you want /Geometry/GetFacility InnerDetector Idet /Geometry/GetFacility BeamPipe BPipe /Geometry/GetFacility PixelDetector Pixel /Atlas/AddDetector TileTBeam � and then moved around /Atlas/AddDetector Bpipe /Idet/AddDetector Pixel /TileTBeam/MoveTo 5 0 2 m /Atlas/AddDetector Idet � OK, *eventually* you have to decide who’s the boss /Atlas/SetAsWorld /Atlas/SetAsWorld A. Dell’Acqua – CERN EP/SFT 8 02/10/2002
The Geometry wrapper � A set of classes ( FadsVolume, FadsPhysicalVolume, FadsRotationMatrix etc..) wrap up the corresponding G4 classes, extend their functionality and self-register on creation to a GeometryManager which keeps a handle to all geometry objects as � organized by detector � At this point one can: � change the visualisation attributes of a volume interactively � change positions and rotations interactively � change physics cuts for a certain volume � assign sensitive detector objects to volumes interactively � remove complete detectors/detector trees � by removing the plug-in, for instance � … by means of the standard G4 (G)UI A. Dell’Acqua – CERN EP/SFT 9 02/10/2002
Sensitive detectors � Abstract interface � They are organized as plug-ins , that an user attaches when they are needed � Assigned interactively to the volumes they must act upon � A volume can become sensitive at run time � General purpose SDs can be implemented for specialized actions � to calculate the thickness in R.L. of a sub-detector A. Dell’Acqua – CERN EP/SFT 10 02/10/2002
Physics � Geant4 physics lists are great for physics customization but generate quite some confusion in the “normal” user � hence: � Physics list are proxied � a Physics list catalog provides a list of the most common lists to choose from (EM, EM+Had…) � New physics lists can always be added (dynamic loading + plug-in) � Normal users choose the most appropriate � Advanced users can define their own... A. Dell’Acqua – CERN EP/SFT 11 02/10/2002
Event Generators � Abstract interface based on the HepMC format Generator � HepMC � Geant4 � Plug-ins � Abstract interface for editing/filtering particles and vertices (plug-ins) � Vertex displacement � η / ϕ filtering � energy/particle type filtering � Primary event (signal) � Secondary events from a different generator � Pile-up at the generator level A. Dell’Acqua – CERN EP/SFT 12 02/10/2002
User Actions � Abstract interface which combines all G4 user actions (and more) into a single class that users must inherit from � Plug-ins � Actions must now be registered interactively � Several UAs can now be run concurrently � Priority mechanism in place to decide which comes first (if needed) A. Dell’Acqua – CERN EP/SFT 13 02/10/2002
Frame Facilities and Analysis � Abstract interface to analysis systems for implementing some histogramming capabilities � currently implemented � Hbook � Root � HTL A. Dell’Acqua – CERN EP/SFT 14 02/10/2002
Other goodies � Automatic access to XML � For materials, colours, detector parameters, “datacards” � User-defined XML “handlers” to be plugged in on-the-fly � Access to the Atlas “NOVA” service (MySQL) � Detector parameters from Geant 3 � Some automatic code generation facilities � For e.g. DetectorFacility’s or UserAction’s � Native persistency scheme built in � Objectivity early on, now Root A. Dell’Acqua – CERN EP/SFT 15 02/10/2002
Status � The three main “actors” are working happily together (modulo cmt) � Can use facilities from both systems (e.g. event generators from Athena and physics from Goofy) seamlessly � Integrating detector geometries for production at the end of this year � 80% complete � Going to a higher level of abstraction for certain components (e.g. SensitiveDetectors) to ensure better compatibility � Athena mostly batch-oriented, Goofy mostly interactive � Some funny batch-interactive mixture possible A. Dell’Acqua – CERN EP/SFT 16 02/10/2002
On a less optimistic note… � We are very much based on the G4 UI.. � …and that does not fit so well with the Atlas “strategy” (if any) � We would certainly be very much behind a full “pythonization” of the G4 UI (besides, Messengers are a real PITA sometimes) � We have not grown a Graphics/Analysis tool of ours… � In the integration phase we are suffering because of lack of functionality (e.g. 2-D graphics, cut views, tree inspection) � Borrow CMS’ Iguana? Bother G4 to death? A. Dell’Acqua – CERN EP/SFT 17 02/10/2002
Conclusions � We are right in the middle of a big, “Big Bang” style move to Geant4 as the main simulation engine � The detector will come together at once � Shifting emphasis from physics to computing for a while � Are we in for some nasty surprise? � Memory, performance, initialization time etc. ARE a concern � We are working hard on parameterising our calorimeters � “GFLASH++” becoming available, looking forward to collaborate with other experiments A. Dell’Acqua – CERN EP/SFT 18 02/10/2002
Recommend
More recommend
