Geant4 in Atlas Entering the production phase See also: A.D. talk - - PowerPoint PPT Presentation
Geant4 in Atlas Entering the production phase See also: A.D. talk @CHEP01, Beijing A.Rimoldis talk @G4 users meeting, SLAC 02 C.Leggetts talk @G4 users meeting, SLAC 02 A n d r e a D e l l A c C E R N q u
Entering the production phase
A n d r e a D e l l ’ A c q u a C E R N E P / S F T d e l l a c q u @ m a i l . c e r n . c h
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
02/10/2002
2
The most complicated detector ever conceived
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
02/10/2002
3
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
02/10/2002
4
Scalability
Scalability
The simulation package must be able to accept the simplest testbeam simulation the complete detector simulation
Clear separation
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 user’s code
Action on demand to
avoid wasting memory
Implement some
middleware on top of G4 for extending its functionality
Dynamic loading +
plug-in techniques for connecting user’s code
Action on demand to
avoid wasting memory
02/10/2002
5
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
02/10/2002
6
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
02/10/2002
7
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");
02/10/2002
8
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 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
9
A set of classes (FadsVolume, FadsPhysicalVolume,
FadsRotationMatrix etc..) wrap up the corresponding G4 classes,
extend their functionality and self-register on creation to a
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
02/10/2002
10
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
02/10/2002
11
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...
02/10/2002
12
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
02/10/2002
13
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)
02/10/2002
14
Abstract interface to analysis systems for
implementing some histogramming capabilities
currently implemented
Hbook Root HTL
02/10/2002
15
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
02/10/2002
16
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
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
02/10/2002
17
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?
02/10/2002
18
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