Geant4 in AtlasEntering the production phase

Andrea Dell’Acqua CERN EP/SFTdellacqu@mail.cern.ch

See also:A.D. talk @CHEP’01, BeijingA.Rimoldi’s talk @G4 users meeting, SLAC ‘02C.Leggett’s talk @G4 users meeting, SLAC ‘02

02/10/2002 A. Dell’Acqua – CERN EP/SFT 2

Atlas simulation in a nutshelln The most complicated detector ever conceivedn The most politicized collaboration ever gathered in HEP

n The most ambitious detector simulation program ever writtenu At the last count we had ~27M volumes in our G3

simulation

n Need to accommodate (under the same umbrella)u Testbeam studiesu Physics studiesu Fast/semi-fast simulation

02/10/2002 A. Dell’Acqua – CERN EP/SFT 3

The main actorsn Athenau Atlas’ chosen software framework«Based on Gaudi«Provides SW environment, services, access to

persistency…n GOOFYu Simulation frameworkuCompletely based on G4

n G4SvcuGaudi service: provides the link

02/10/2002 A. Dell’Acqua – CERN EP/SFT 4

Goofy’s Design principlesnn ScalabilityScalability

u The simulation package must be able to accept « the simplest testbeam simulation « the complete detector simulation

nn Clear separationClear separation between “core” software and user implementationu 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

n Implement some middleware on top of G4 for extending its functionality

n Dynamic loading + plug-in techniques for connecting user’s code

n Action on demand to avoid wasting memory

n Implement some middleware on top of G4 for extending its functionality

n Dynamic loading + plug-in techniques for connecting user’s code

n Action on demand to avoid wasting memory

02/10/2002 A. Dell’Acqua – CERN EP/SFT 5

The simulation programn has no geometry

u Users build it interactively at initialization time

n has no physicsu Users choose from a catalog, depending on what they want to dou ..or implement their own, and add it to the catalog

n has no kinematicsu See above…

n is an empty box

02/10/2002 A. Dell’Acqua – CERN EP/SFT 6

Stepsn The “standard” G4 framework is too static for our purpose: we try

and get rid of it by maintaining full compatibility with G4u no UserDetectorConstruction, no UserPhysicsList…

n Provide a set of services that users can refer tou MaterialManageru DetectorFacilityu PhysicsListCatalogu VisCenter…

n Use the Geant4 (G)UI facilities for re-creating all connectionsn Make sure that users can build theirtheir application (factorization)nn Save memorySave memory, as much as one can, use proxies and lightweight

objects (memory has a price, after all).

02/10/2002 A. Dell’Acqua – CERN EP/SFT 7

Geometry organizationn Geometry is naturally split into Detectors

u A DetectorFacility class is provided for thisu Users must inherit from DF and (in principle) just implement a BuildGeometry() method

n There is no predefined detector organization, users build their experiment at run timeu Atlas logically contains the Atlas IDET, but you can make it such that

the IDET contains Atlasn 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");

02/10/2002 A. Dell’Acqua – CERN EP/SFT 8

Geometry Organizationn DetectorFacilities are accessible at run time through the

catalog

n and define their own UI directory

n and can be combined together in the way you want

n and then moved around

n OK, *eventually* you have to decide who’s the boss

/Geometry/GetFacility PixelDetector Pixel

/TileTBeam/GetDescription TILE

/Atlas/AddDetector TileTBeam

/TileTBeam/MoveTo 5 0 2 m

/Atlas/SetAsWorld

/control/ReadXML standard_materials.xml/control/ReadXML 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

02/10/2002 A. Dell’Acqua – CERN EP/SFT 9

The Geometry wrappern A set of classes (FadsVolume, FadsPhysicalVolume,

FadsRotationMatrix etc..) wrap up the corresponding G4 classes, extend their functionality and self-register on creation to a

n GeometryManager which keeps a handle to all geometry objects as organized by detector

n At this point one can:u change the visualisation attributes of a volume interactivelyu change positions and rotations interactivelyu change physics cuts for a certain volumeu assign sensitive detector objects to volumes interactivelyu remove complete detectors/detector trees

« by removing the plug-in, for instance

n … by means of the standard G4 (G)UI

02/10/2002 A. Dell’Acqua – CERN EP/SFT 10

Sensitive detectorsn Abstract interfacen They are organized as plug-ins, that an user attaches

when they are neededn Assigned interactively to the volumes they must act

uponu A volume can become sensitive at run timeu General purpose SDs can be implemented for specialized

actions « to calculate the thickness in R.L. of a sub-detector

02/10/2002 A. Dell’Acqua – CERN EP/SFT 11

Physicsn Geant4 physics lists are great for physics customization

but generate quite some confusion in the “normal” usern hence:

u Physics list are proxiedu a Physics list catalog provides a list of the most common lists

to choose from (EM, EM+Had…)u New physics lists can always be added (dynamic loading +

plug-in)

n Normal users choose the most appropriaten Advanced users can define their own...

02/10/2002 A. Dell’Acqua – CERN EP/SFT 12

Event Generatorsn Abstract interface based on the HepMC format

Generator ð HepMCð Geant4

n Plug-insn Abstract interface for editing/filtering particles and

vertices (plug-ins)u Vertex displacementu η/ϕ filteringu energy/particle type filtering

n Primary event (signal)n Secondary events from a different generatorn Pile-up at the generator level

02/10/2002 A. Dell’Acqua – CERN EP/SFT 13

User Actionsn Abstract interface which combines all G4 user actions

(and more) into a single class that users must inherit from

n Plug-insn Actions must now be registered interactivelyn Several UAs can now be run concurrentlyu Priority mechanism in place to decide which comes

first (if needed)

02/10/2002 A. Dell’Acqua – CERN EP/SFT 14

Frame Facilities and Analysis

n Abstract interface to analysis systems for implementing some histogramming capabilities

n currently implementeduHbookuRootuHTL

02/10/2002 A. Dell’Acqua – CERN EP/SFT 15

Other goodies

n Automatic access to XMLu For materials, colours, detector parameters, “datacards”uUser-defined XML “handlers” to be plugged in on-the-fly

n Access to the Atlas “NOVA” service (MySQL)uDetector parameters from Geant 3

n Some automatic code generation facilities u For e.g. DetectorFacility’s or UserAction’s

n Native persistency scheme built inuObjectivity early on, now Root

02/10/2002 A. Dell’Acqua – CERN EP/SFT 16

Statusn The three main “actors” are working happily together

(modulo cmt)uCan use facilities from both systems (e.g. event generators

from Athena and physics from Goofy) seamlesslyn Integrating detector geometries for production at the end

of this yearu 80% completeuGoing to a higher level of abstraction for certain components

(e.g. SensitiveDetectors) to ensure better compatibilityn Athena mostly batch-oriented, Goofy mostly interactiveu Some funny batch-interactive mixture possible

02/10/2002 A. Dell’Acqua – CERN EP/SFT 17

On a less optimistic note…n We are very much based on the G4 UI..u…and that does not fit so well with the Atlas “strategy” (if any)

uWe would certainly be very much behind a full “pythonization” of the G4 UI (besides, Messengers are a real PITA sometimes)

n We have not grown a Graphics/Analysis tool of ours…u In the integration phase we are suffering because of lack of

functionality (e.g. 2-D graphics, cut views, tree inspection)u Borrow CMS’ Iguana? Bother G4 to death?

02/10/2002 A. Dell’Acqua – CERN EP/SFT 18

Conclusionsn We are right in the middle of a big, “Big Bang” style move

to Geant4 as the main simulation engineu The detector will come together at onceu Shifting emphasis from physics to computing for a while

n Are we in for some nasty surprise?uMemory, performance, initialization time etc. ARE a concern

n We are working hard on parameterising our calorimetersu “GFLASH++” becoming available, looking forward to

collaborate with other experiments