G4Atlas a brief introduction

1
G4Atlas a brief introduction

• Andrea DellAcqua
• CERN PH/SFT
• dellacqu_at_mail.cern.ch

this slides are available at http//home.cern.c
h/ada/tutorial.ppt
2
What is this?

• I cant teach you in 15mins how to use a
  simulation infrastructure which took years of my
  and other peoples life
• We can try and give you a feeling of how to run
  it and what should you expect if you decide you
  want to get your hands dirty with it
• Let my try to explain what this thing is, first
  of all

3
G4Atlas

• This is NOT a simulation program
• This is a simulation infrastructure, aimed at
  permitting you to develop your favourite
  application without writing too much code and by
  making good use of possibilities offered by
  Geant4 and by the ATLAS SW environment
• The underlying idea is that people develop their
  own detector code separately and we provide the
  facilities for getting everything together in a
  consistent application
• Users must not be forced to know anything about
  G4 or athena, if they dont want to
• Now, on with the pictures, let me show we can we
  do with G4Atlas today

4
What do you need to know

• If you are a user who just wants to run a G4
  application (e.g. Armin Nairz in production mode)
• Basically nothing
• If you are a developer who wants to implement a
  G4 based application (e.g. Manuel Gallas for the
  CTB)
• Application basics, some G4 (macro language)
• If you are a developer who wants to implement
  some detector simulation (e.g. Davide Costanzo
  for the IDET)
• Application basics, Geant4, very little athena
• If you are a simulation core developer
• Probably you should be working in you office,
  instead of being listening to my rants

5
Some design principles caveats

• G4Atlas was designed to be capable of describing
  different experimental situations, hence the
  somewhat weird lookout
• G4Atlas runs empty by default (no geometry, no
  physics), hence some configuration work is
  needed
• athena and Geant4 are concurrent applications.
  Using G4 from athena requires some compromise
  (although better integration would be possible)
• The whole application is based on the use of
  plug-in components at run time, and as such
  contradicts the basic athena phylosophy (which is
  rather static)
• Dynamic linking in G4Atlas (DLL if you want) is
  completely different from the athenas one and
  used for different purposes
• The KISS rule

6
Components

• One service G4Svc
• Provides the link between G4 and the athena world
  and implements basic functionality such as
• G4 initialization
• Event handling
• Link to kinematics
• It can in principle steer the simulation by
  itself
• One algorithm G4SimAlg
• Takes care (by internally using the G4Svc
  facilities) of initializing G4 properly and to
  simulate events
• Any additional component is flavourless (any
  dependence from athena via services, as for
  instance StoreGate)
• 30 packages detector specific code

7
How to run it

• In principle, it is just matter of adding
  G4SimAlg in the DLLs and as TopAlg (G4Svc is used
  internally)
• ApplicationMgr.DLLs G4SimAlg
• ApplicationMgr.TopAlg G4SimAlg
• this is enough for setting up a G4 environment
  in e.g. the TestRelease
• A special pseudo-package, AtlasG4Sim is provided
  for setting up the whole ATLAS detector
  simulation
• Check out AtlasG4Sim from Simulation/G4Sim/AtlasG4
  Sim
• Build it like you would for the TestRelease
• cmt config
• cmt broadcast cmt config
• cmt broadcast gmake
• source setup.sh
• Run athena jobOptions.AtlasG4Sim.txt (2 muon
  events through the ATLAS detector)

8
Some jargon, to start with

• Physics list
• A menu of physics processes, which will be
  activated in the detector simulation
• DetectorFacility
• A class which represents the entry point for a
  sub-detectors geometry. Sets up the geometry of
  the sub-detector envelope and its contents
• Hit
• A snapshot/record of a physical interaction in a
  volume
• SensitiveDetector
• A class which is supposed to utilize
  geometrical/physical information to create
  simulation hits. A SensitiveDetector object, when
  assigned to a volume, makes it sensitive
  (call-back mech.)
• UserAction
• User defined class, utilized for interacting with
  the program at various levels (to add, for
  instance, analysis code)

9
Setting up a G4Atlas application

• As it would be too complicated to set up a
  (possibly generic) application from job options,
  G4 macro commands are used for undertaking all
  necessary steps in initializing an application
• Geometry creation the experimental layout is
  built by combining DetectorFacilities together,
  as you would do with big LEGO blocks
• Physics initialization a user can decide which
  physics menus will be run from a list of possible
  choices, or define his/her own
• Detector sensitivity selected volumes are made
  sensitive by assigning to them a
  SensitiveDetector object
• Magnetic field field maps can be defined for
  the whole detector/selected regions
• User actions users decide how to interact with
  the program, at the level of run/event/step/track/
  stack
• Detector/event visualization
• Macro commands are grouped into macro files
  (extension .mac) which are typically run in
  cascade

10
A couple of job options

• G4Svc.FADSMacro
• As the program must work out of a (list of) G4
  macro(s), this option is used for choosing which
  macro(s) must be run at initialization time
• From jobOptions.AtlasG4Sim.txt
• G4Svc.FADSMacro env.macAtlas.macPhysicsList.m
  acFilters.mac
• If no macro is specified and the program is run
  in batch mode, the job will run uninitialized
  and will most likely crash
• G4Svc.InteractiveG4
• As the application consists mostly of G4 code, it
  is still possible to run an interactive G4 shell
  for setting up geometry, physics
• G4Svc.InteractiveG4 true
• ?the program will start and stop soon in an
  interactive shell ( PreInitgt prompt)
• G4Svc.InteractiveG4 false
• ?the program will start and go to a hopefully
  happy end
• Other options are implemented for G4Svc/G4SimAlg
  which are not relevant to this discussion

11
Setting up the detector geometry

• Detector geometry is set up by combining
  DetectorFacilities like big LEGO blocks
• DetectorFacilities become available by loading
  the appropriate library at run time
• /load PixelG4Geometry
• the DetectorFacility plug-in registers itself in
  a catalog from where it can be retrieved
• /Geometry/GetFacility TRTEndCap TRTForwardEndCap
• /Geometry/GetFacility TRTEndCap TRTBackwardEndCap
• Facilities can be positioned within other
  facilities, moved, rotated
• /IDET/AddDetector TRTForwardEndCap
• /IDET/AddDetector TRTBackwardEndCap
• /TRTBackwardEndCap/RotateX 180 deg

(from pixelgeometry.mac)
(from trtgeometry.mac)
(from trtgeometry.mac)
12
Geometry organisation in AtlasG4Sim

• Sub-detector geometries are built in macro files
  which are then called in cascade

Atlas.mac
atlas_envelopes.mac
InnerDetectorGeometry.mac
LarCal.mac
pixelgeometry.mac
sctgeometry.mac
TileCal.mac
trtgeometry.mac
MuonSystem.mac
13
GeoModel interface

• An ad-hoc interface has been envisaged to build
  detectors out of a GeoModel description in memory
• Geo2G4
• GeoModel has to be initialised and the various
  detector managers built (cfr. jobOptions.AtlasGeoG
  4Sim.txt)
• Geo2G4Svc must be declared as an ExtSvc
• ApplicationMgr.ExtSvc Geo2G4Svc
• Detectors can be built out of a special
  DetectorFacility provided on purpose, in a
  generic fashion (cfr. InnerDetectorGeoGeometry.mac
  )
• /Geometry/GetFacility GeoDetector SCTSCT
• Detectors built in this way can be used in place
  of hand-coded ones
• Customization of Geo2G4/VolumeBuilders well
  beyond the scope of this talk

14
Envelopes and resizeable volumes

• Envelopes for the ATLAS detector units are
  provided as DetectorFacilities (see
  atlas_envelopes.mac)
• Dimensions from the NOVA DB
• Dimensions can be changed by reading in an XML
  file (datacards)
• This is unfortunately the MAJOR source of
  problems we have
• Generic (resizable) envelopes of various shapes
  provided for the implementation of the CTB
• Size, material, sometimes the basic shape can be
  changed interactively
• Beyond the scope of this tutorial, see the CTB
  simulation package if you are interested
• Basically, the functionality for an interactive
  geometry editor is in place (although Im
  reluctant to make it available)

15
Physics lists

• First thing you learn when you deal with G4
  never get too acquainted with physics list
• Let someone else do the work for you
• Fine, we let you choose from a menu of PLs
• /load G4PhysicsLists
• /Physics/PrintLists
• Please refer to G4 doc for details of the
  various PLs
• When youre happy with a choice, just get a PL by
  name, the program will do the rest
• /Physics/GetPhysicsList QGSP_GN
• we suggest anyway that you explicitly construct
  the PL you chose
• /Physics/ConstructPhysicsList
• You can also set the general cut for the whole
  detector
• /Physics/SetGeneralCut 1 mm

(from PhysicsList.mac)
16
More on physics

• We try as much as we can to provide PLs as they
  come out of the box
• If a special process is needed that is not in the
  PL in use, we provide a special procedure to add
  it on top of the physics menu, without modifying
  any piece of code
• If a special value of the cut in range is
  needed for a particular sub-detector/region, we
  provide the possibility of interactively defining
  region/cut associations interactively
• We also provide the possibility of setting cuts
  in energy on a volume base, interactively
• All this is, of course, out of the scope of this
  introduction

17
Kinematics

• G4Atlas expects an HepMC event on input. This
  means that
• ATLAS event generators can be run on-line
• As in AtlasG4Sim proper
• Events can be read back from Root/Pool files
• As Wim will demonstrate later on
• G4 specific event generators can still be used
• But I cant talk about them
• The original HepMC event is translated into
  another HepMC event (truth event). Special filter
  mechanisms are applied at this point (e.g. vertex
  spread)
• /Filters/Vertex/toggle ON
• /Filters/Vertex/Spread 0.01 0.01 50 mm
• /Filters/EtaPhiFilter/toggle ON
• /Filters/EtaPhiFilter/EtaInterval -7. 7.

(from Filters.mac)
18
Advanced kinematics

• The original G4 event loop is still available
• But Im sworn to silence
• The information about primary particles/vertices
  is propagated forward and it is accessible at any
  moment during tracking (hit-truth association)
• User intervention is still possible at the single
  track level (see UserActions)
• Customized track stacking is possible, but this
  must happen at application level (as a normal
  user you cant do it)

19
Magnetic field

• As for Physics Lists, magnetic field maps are
  provided in a catalog, where an user can get them
  from
• /load G4Field
• /MagneticField/Select AtlasField
• An additional initialization step may be
  required
• /MagneticField/Initialize
• With the latest versions of G4Atlas (7.7.0 and
  later), field maps can be assigned to single
  volume hierarchies and different field maps can
  co-exist in different regions of the exp. Setup
• CTB requirement

(from AtlasField.mac)
20
A bit more on volumes

• In G4Atlas, all volumes (G4 Logical volumes for
  those who know..) are accessible at run time
• Volumes are identified by
• Their sub-detector name (scope)
• Their proper name
• A volume name will then look something like
• PixelSensitiveWafer
• As an example, you can obtain a list of all
  defined volumes (categorized by detector) with
  the command
• Geometry/ListAllVolumes
• It goes without saying that, if volumes can be
  accessed, they can also be modified

21
Sensitive Detectors and hits

• A SensitiveDetector is a class whose aim is to
  produce hits, when a particle goes through a
  volume
• SensitiveDetectors in G4Atlas are plug-ins
• A volume becomes sensitive when a SD is
  associated to it
• Volume-SD associations are established at run
  time
• /load PixelG4_SD
• /SenDetector/UseSensitiveDetector PixelSensorSD
  PSD
• /Geometry/AssignSD Pixel PixelsiBLayLog PSD
• With this mechanism in place, volumes can become
  sensitive at any moment (even at run time)
• SDs are (normally) a detector business, its up
  to them to produce hits containing the correct
  info

(from pixelgeosensitive.mac)
22
Hits and persistency

• Hit definition is purely a detector business
• Not entirely true though. We use hits to store
  some other information at tracking time, as (for
  instance) records of particles crossing a certain
  surface in the detector
• So is their persistification
• Hits persistified by means of the AthenaPool
  machinery
• Completely transparent to the occasional user
• All you have to do is to include the appropriate
  job option fragment
• include "HitAthenaRootWriteOptions.txt"
• (and naturally hope that someone did his/her work
  properly)

23
User Actions

• Provide the user with a mechanism to interact
  with the simulation program at various levels
  (track, stack, run, event, step)
• Provide the possibility of implementing
  occasional actions that one may wish to have but
  which arent necessarily part of the application
  (e.g. an event timer)
• ApplicationActions provide the possibility of
  interfacing to a piece of code which isnt
  exactly kosher
• UserActions are, once more, plug-ins
• Some UserActions must be explicitely activated

24
User Actions (contd)

• Three different types of actions
• StackingAction
• Allows to customize the track stacking procedure
• TrackingAction
• Run at the beginning and the end of each track
• UserAction
• Give the user the possibility of interacting with
  the program at the beginning and the end of a
  run, at the beginning and the end of each event,
  at every step
• Sum up the functionality of G4UserRunAction,
  G4UserEventAction, G4UserSteppingAction (for YOUR
  convenience)
• You can have as many of these as you want!
• UserActions MUST be activated
• /Actions/RegisterForAction MyAction BeginOfEvent
• /Actions/RegisterForAction MyAction Step

25
User Actions (contd)

• A package called G4UserActions has been set up
  (Simulation/G4Utilities/G4UserActions) which
  contains a few examples and a couple of actions
  of common use
• /load G4UserActions
• TestAction1 and TestAction2 are there for you to
  play and figure out how to use actions, as well
  as for providing a template for any action you
  may wish to implement
• The G4SimTimer is the most commonly used action
• /Actions/RegisterForAction G4SimTimer BeginOfRun
• /Actions/RegisterForAction G4SimTimer
  BeginOfEvent
• /Actions/RegisterForAction G4SimTimer EndOfEvent
• /Actions/RegisterForAction G4SimTimer EndOfRun

26
Some words about graphics

• You probably guessed it by now, the standard G4
  visualization machinery is available from an
  interactive session
• Some additional possibilities, which are NOT
  offered by vanilla G4
• Colors are normally defined in XML format
  (color.xml)
• ltColor name"FloralWhite" red"255" green"250"
  blue"240" /gt
• Volume vis. attributes CAN be changed
  interactively in G4Atlas
• /Geometry/Volumes/SetInvisible
• /Geometry/Volumes/SetVisible Pixel
• /Geometry/Volumes/SetColor PixelSensitiveWafer
  FloralWhite
• Detector visualization is possible while you are
  building it, bit by bit
• Event graphics is implemented and working, but
  there is a grand total of 1.5 people who know how
  to use it
• Far beyond the scope of this tutorial, please
  refer to the documentation if interested

27

• Well, this is all I wanted to say for the moment
• This is certainly not enough for you to embark
  onto a full-speed application implementation, but
  I hope I managed to give you a feeling of what
  you should expect from it if you try
• Experience with new users has demonstrated that
  the learning curve is very steep, sometimes
  exceedingly so for me to keep up
• We are now seeing people sticking to the G4Atlas
  environment for running generators,
  reconstruction and what else, some time I wonder
  if we did not do a too good job