Geant4 in Atlas

1
Geant4 in Atlas

• Entering the production phase

See also A.D. talk _at_CHEP01, Beijing A.Rimoldi
s talk _at_G4 users meeting, SLAC 02 C.Leggetts
talk _at_G4 users meeting, SLAC 02
Andrea DellAcqua CERN EP/SFT dellacqu_at_mail.cern.c
h
2
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

3
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

4
Goofys Design principles

• Scalability
• The simulation package must be able to accept
• the simplest testbeam simulation
• the complete detector simulation
• Clear separation between core software and user
  implementation
• the framework
• does not depend on what the users want to do
• provides maximum flexibility and freedom to the
  user who wants to implement his/her own code
• must be light

• Implement some middleware on top of G4 for
  extending its functionality
• Dynamic loading plug-in techniques for
  connecting users code
• Action on demand to avoid wasting memory

5
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

6
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 application
  (factorization)
• Save memory, as much as one can, use proxies and
  lightweight objects (memory has a price, after
  all).

7
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 DetectorFacilityEntryltTileSectiongt
calo("TileSection")
8
Geometry Organization

• DetectorFacilities are accessible at run time
  through the catalog
• and define their own UI directory
• and can be combined together in the way you want
• and then moved around
• OK, eventually you have to decide whos the boss

/control/ReadXML standard_materials.xml /control/R
eadXML pixel_materials.xml /load
DetectorEnvelopes /load Pixels /load
BeamPipe /Geometry/GetFacility AtlasDetector
Atlas /Geometry/GetFacility InnerDetector
Idet /Geometry/GetFacility BeamPipe
BPipe /Geometry/GetFacility PixelDetector
Pixel /Atlas/AddDetector Bpipe /Idet/AddDetector
Pixel /Atlas/AddDetector Idet /Atlas/SetAsWorld
/Geometry/GetFacility PixelDetector Pixel
/TileTBeam/GetDescription TILE
/Atlas/AddDetector TileTBeam
/TileTBeam/MoveTo 5 0 2 m
/Atlas/SetAsWorld
9
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

10
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

11
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, EMHad)
• New physics lists can always be added (dynamic
  loading plug-in)
• Normal users choose the most appropriate
• Advanced users can define their own...

12
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

13
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)

14
Frame Facilities and Analysis

• Abstract interface to analysis systems for
  implementing some histogramming capabilities
• currently implemented
• Hbook
• Root
• HTL

15
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. DetectorFacilitys or UserActions
• Native persistency scheme built in
• Objectivity early on, now Root

16
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

17
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?

18
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