# Presentation: 055358

## ATLAS Simulations - What Did We Learn From the Past

- Infrastructure Is As Important As Physics !
- Geometry Model
- Debugging Tools
- Hit Access Service

## Dice95 (Atlsim)

- Third generation of the ATLAS simulations tools
- Stable GEANT3 simulation framework since 95
- Improved memory management
- Elastic ZEBRA (using malloc)
- No limits on number of tracks, vertices, hits etc    (apart from physical memory limits)
- Interfaces to existing and future services
- Geant3/PAW,  MySQL ...  ROOT and even more
- Strictly hierarchical design to separate detector specific  code from the infrastructure

## Hierarchical Design

- Open system interconnection (OSI) model as example: functionality in term of layers
- Basic (physical) layer - platform dependant code, system libraries,graphics etc
- Low (logical) layer - ZEBRA, DZDOC,HIGS
- Upper (transport)  - G3, paw+Kuip, (DB, root)s
- System (session) – advanced Geant interface
- User (application) - modules in F, AGI, C++
_***Communications across layers are prohibited***_

## Few Numbers at a Glance

- 25,5 millions distinct volume copies
- 23 thousands different volume objects
- 4,673 different volume types
- Only 33 K lines of code (with digitization!)
- No step routine is needed for most of the detectors,  no “if statement” problem
- Few hundred pile-up events possible
- About 1 million hits per event on average

## ATLAS Detector View With G3

## Geometry Description

-  Geometry description language is a must !
- Geometry is never as stable as we want it.
- Detectors have parameters which may describe geometry evolution.
- Most of the geometry dimensions has to be calculated using parameters.
- Both input parameters and calculation results should be available to the reconstruction.
- A mechanism of keeping both parameters and calculation results is needed.

## Geometry Model

- Complete geometry model is created in the computer memory as a result of code execution with a set of input parameters coming from:
- Default code versions
- Database (MySQL supported)
- Data card parameters and version input
- Selection is done at run-time (user controlled)
- Resulting geometry is _***persistent***_***, ***as well as all selected input parameter structures

## Database Interface

- Loading geometry data or opening an existing  configuration creates a relational database in memory  - a subset of the full database.
- Selection of an actual copy of each structure (instantiation) is done by the _***use***_ statements.
- Any variable from the structure can be used as a selection key – within selected configuration.
- USE processor in AGI makes dynamic brokerage in case the structures in the code differs from DB.

## ATLAS Geometry

- Modules: 92
- Structure types: 120
- Instances: 458 (with AMDB)

## GeometryStructures

- Contain only independent (basic) parameters
- Parameter values: 11779
- Dimensions and positions are calculated in the code

## How This DB Looks Like ?

## Geometry Parameter-example:

-  ----Data of Bank/UpBank: PXBG/PXPA
-         Doc Version: 31 MAY 2000 –
-  1  -        1205.  - usage counter
-  2  -       1.000   - system version
-  3  version  1.0  - VERSION
-  4  rmin    4.50   - OVERALL MIN RADIUS
-  5  rmax   25.00 - OVERALL MAX RADIUS
-  6  hlen    345.0  - OVERALL HALF LENGTH
-  7  Nlay    3.000 - MAXIMUM NR. OF LAYERS
- 8  Nframe   16.  - NR.OF SUPPORT FRAMES
- How to get this information post factum ? => see four

## From Macro to Minor Details

## Debugging Tools Are Important !

## Graphical Access to Detail Level

## Access to Material Distribution 

- Make a cut, measure a distance, show a hit, ...
-      and much more ! => see demo at one

## Exporting G3 Geometry

- TDataset

- TVolume

- TVolumePosition

- TVolumePosition
-  list

- TVolumeView

- TShape

- TGeant

- TNode

- TVolumeView

- ctor

- ctor

## Atlas 3D 

## 3D cut

## Inner Detector in Open GL

- Same geometry can be seen by different viewers:
-                          => see demo at one

## Hit Service: Definitions

- Universal hit definition:
*HITS volume measurement:bin_or_bits:(a,b)...*
- A hit is a container of _**measurements**_, representing a piece of particle trajectory.
- Most of the measurements** **are similar for all detectors and rather trivial:
- X,y,z – local or global, momentum and directions.
- eta or phi, time of flight, deposited energy.
- Distance of the closest approach to a wire.
- Repeating their coding was error-prone.

## Hit Service: Mixing and Sorting

- Universal hit sorting   =>  see demo at three.
- Hits are produced along a particle trajectory, but most often are analyzed together in a detector element.
- Hits are often produced in different events, but still analyzed together in the same detector element.
- A flexible hit navigation may solve both tasks.
- It also can be detector independent.

## Hit Service: History

- It is often desirable to determine the origin of a hits from secondary tracks, produced during simulations. However in practice  it is hard to save all secondary tracks.
- DICE can save only those secondaries, which have produced a hit in specified detectors or made a specified interaction.
- The vertex entry of secondary tracks keeps their closest ancestor as well as the originating process and volume where it happened.

## Hit Service: ROOT Access

**class TPoints3DABC**
**(*****from ROOT G3D*****)**

**TGeantHits3D**

**TGeantHits()**
**...**
**GetNextHit(Int_t indx)**

- GZEBRA

**aghitget()**

**aghitset()**

##  Conclusions

- Past experience ***is*** important
- Many good features was exposed to users
- Moving OO should make live better
- ... and simulations even more reliable