{'fraction_non_alphanumeric': 0.014763779527559055, 'fraction_numerical': 0.006658175081056044, 'mean_word_length': 5.149163403346386, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Simulation strategies using FATRAS and Geant4 for a future upgrade of the ATLAS tracking detectors

With the completion of installation and commissioning of the ATLAS detector in 2008, the collaboration has increased its effort focussing on the upgrade of the ATLAS detector devices that should take place in parallel to a luminosity upgrade of the Large Hadron Collider (LHC). The upgrade of the ATLAS tracking detector will be performed in two steps, starting from the insertion of a new innermost pixel silicon layer to a full replacement of the inner tracking devices. Design decisions based on Monte Carlo simulation are necessary within the near future to allow hardware research and development and finally to guarantee a completion of the detector construction until the planned intervention periods.


Introduction
The year 2008 has not only marked the completion of deployment and commissioning of the ATLAS detector, to be operated at the Large Hadron Collider (LHC) at CERN, but has also brought first collected beam and continuing cosmic ray data. Within this exciting period the collaboration started drawing more attention to the planning of a future upgrade of the ATLAS detector devices. The current ATLAS detector reassembles the classical layout of a particle physics collision experiment: an innermost vertex and tracking detector is enclosed by both, an electromagnetic and hadronic calorimeter and finally surrounded by a large muon spectrometer. The innermost tracking detector is embedded in a solenoidal magnetic field and realised as a silicon pixel detector at inner radii, followed by silicon strip modules (SCT) and a straw tube detector, the so-called transition radiation tracker (TRT) at the outermost regions. Although almost all parts of the ATLAS detector are planned to undergo upgrade intervention, the inner detector is with this respect of particular concern: within the years of operation until the LHC machine upgrade, the silicon detector devices close to the beam line will have suffered from high radiation damage and a replacement will be inevitable. The initial step of the ATLAS detector upgrade will thus be the insertion of a new innermost pixel layer into the current layout to recuperate and even enhance the vertex measurement capability after about five years of operation. Additionally, the projected luminosity levels will create extremely high occupancies that will require higher a granularity of the entire inner detector. It will render the TRT with its limited number of about 400 000 channels practically unusable.
This document is organised as follows: in Sec. 2 a general introduction to the planned LHC upgrade scenarios is given and the immediate consequences for the current and future ATLAS detector layout are outlined. Section 3 contains a description of the strategies of the ATLAS collaboration to establish a realistic detector simulation that should result -together with engineering and logistical constraints -in the final upgrade layout of the ATLAS detector. Section 4 will briefly mention CPU consumption considerations and Sec. 5 will give a short conclusion to this document.
The presented document should (due to the matter of the presented field) not be understood as a reference for performance estimates of a future ATLAS inner tracking detector 1 . In contrary, the authors would like to emphasise that at this stage only the strategies how to arrive at this performance estimation and finally at an optimal detector layout can be given.

LHC Upgrade Scenarios and Consequences
Despite of the appealing success of the LHC startup in October 2008, the then following weeks have also revealed the complexity of operating such a unique machine 2 . It is a natural consequence that upgrade schedules are based on current understanding and progress of the LHC operation and that extrapolations may be obsoleted by reality at some point. The quoted numbers for both dates and future machine specifications should thus be taken with a grain of salt. In any case, however, they should be revised when future has become present. The main directive for the detector upgrade seems to be a relatively easy task: be prepared at the earliest scheduled time for the highest luminosity foreseen at this stage. Furthermore, since only one entire replacement of the inner detector may be possible, the authors tend to formulate this even stronger and tend to think that the preparation for the highest luminosity to be reached has to be done. Table 1 summarises the preliminary scenarios for the LHC upgrade and the associated main parameters.
The most pronounced consequence of the LHC upgrade is an obvious one: it is the enormously increased number of particles that are created per bunch crossing. Since beam energy and thus the production cross sections are planned to be kept at an unchanged level, this is directly related to the number of underlying diffractive and non-diffractive collision events. Diffractive events are being left out in current studies for simplicity and convenience, but will have to be revisited in the future. The number of non-diffractive minimum bias collisions during one bunch crossing, in the following referred to as pileup events increase dramatically from 21 events on average at the LHC design luminosity of 10 34 cm −2 s −1 to a maximum mean value of about 400 in the last upgrade phase.

Layout Considerations
The increased particle density in the detector has direct consequences for the detector design: higher granularity is needed in order to resolve the individual track trajectories to allow a strong vertex separation used to identify the single pileup vertices. To achieve this, the current ATLAS upgrade plans foresee a reduction of the pixel length in beam direction from 400 µm to 250 µm or less in order to allow a better spatial separation along the beam axis and to reduce the effective hit occupancy per module. In order to reduce the number of false track candidates a supplemental precision layer may be needed as an additional track constraint for pattern recognition.

Upgrade Simulation
Currently four different simulation strategies are used for ATLAS detector upgrade studies, for convenience labelled as Geant3, Geant4 (in the following also referred to as full simulation), FATRAS and LCSIM. Their main specifications are listed in Tab.
2. An appealing aspect of having these different approaches is that they share common modules and implement separate approaches at the same time. This is true for both simulation and reconstruction and is in particular present in the relationship between the full simulation chain (detector simulation performed by Geant4 [2]) and the Fast ATLAS Track Simulation (FATRAS) [3] chain. Both are embedded in the ATLAS software framework ATHENA [4] and run one identical subsequent track reconstruction, the ATLAS New Tracking (NEWT) [5]. Embedding the upgrade Geant4 and FATRAS simulation in the common ATLAS software framework brings a big advantage: it allows to use reconstruction, high level analysis, validation and visualisation tools that are currently used within the collaboration. This eases the validation and understanding of the different concept layouts and in particular the comparison to the current ATLAS setup. Figure  1 shows a single hard quark scattering event in an concept ATLAS upgrade detector with four pixel layers and five silicon strip layers in the barrel displayed with the ATLAS 3D event display VP1 [6]. Both the full and FATRAS simulation will be described to more detail in Secs. 3.1 and 3.2, respectively. The LCSIM [7] simulation has been integrated from simulation efforts carried out for the design of detectors planned for the International Linear Collider (ILC). It shares the same underlying physical tracking and interaction engine, Geant4, with the full simulation in ATLAS. Finally, also an updated version of the predecessor simulation, Geant3 [8], in combination with the old ATLAS reconstruction framework is available. This setup has been used for the design of the current ALTAS detector layout and has left us with a great detector. Furthermore, it spans a reassuring arc back to the beginning of the ATLAS experiment.

The Geant4 Simulation Toolkit
The Geant4 simulation toolkit is indisputably the most commonly used full detector simulation in modern particle physics, but has also spread out to many other areas where Monte Carlo simulation of the interactions of moving particles with material is necessary. In ATLAS, the Geant4 simulation replaced the former Geant3 implementation in 2003 and has since then served as the main simulation engine since then. Remarkable agreement with data being collected in the test beam setups [9] could be achieved. The ATLAS full simulation chain consists of event generation (performed by common event generation engines), the Geant4 detector simulation and the digitisation process. In the full detector simulation sensitive and non-sensitive detector material has to be distinguished. Only in sensitive detector elements charge deposition or ionisation cells are simulated in order to be processed by the digitisation modules. The latter are usually specific to the detector technologies and hence not part of common simulation libraries. The full ATLAS detector simulation employs a very detailed geometry description that is generated from the common geometry representation GeoModel [10]. As sensitive detector parts are used in digitisation in addition to the simulation and finally also in the event reconstruction they are encapsulated in a separate description inside GeoModel.
A fully detailed description of the detector setup requires the definition of a huge number of geometrical objects and is not feasible for every single test setup during the design phase of the upgrade detector. A fast alternative program would be desirable that allows for flexible changes of detector layout and sensor specifications while yielding good agreement compared to results obtained by the Geant4 simulation.

The FATRAS simulation
Recently, a fast alternative track simulation has been developed as part of the ATLAS framework. It is based on performance optimised algorithmic tools from the event reconstruction and the simplified reconstruction geometry. In ATLAS, the reconstruction geometry is implemented in a dedicated geometry package, the so-called TrackingGeometry [11]. This geometry model uses an internal navigation scheme, characterised by a fully connected geometry. Volume and layer entities are based on the ATLAS surface class that also builds the main core of the ATLAS tracking event data model [12] and can be naturally used with the ATLAS extrapolation engine [13]. A predictive navigation module is made available by building a fully attached set of volumes that point to their associated neighbours and hence following the particle through the detector yields the intersected layers and (detector) surfaces on the one hand, and the subsequent detector volume to traverse on the other. In this step sensitive detector parts are described to the same detail as in the full simulation setup, while the remaining geometry parts are simplified to layers. An automated procedure maps the simulation material onto this simplified layer frame, which generally achieves good agreement between simulation and reconstruction material budget. Figure 2 shows a comparison between simulation and reconstruction material description for a sample upgrade layout (without pixel endcaps).  Figure 2. Comparison between the material budget for a simplified upgrade test layout described by the simulation geometry used in Geant4 and the reconstruction geometry description that is used for the fast track simulation. It is evident that -in comparison to the ATLAS startup layout [14] -the material is underestimated in this setup which is also missing the pixel endcap descriptions entirely.
To create a full Monte Carlo simulation from mainly reconstruction algorithms, several parts of the reconstruction tools (e.g. the stochastic material effects integration in the track extrapolation) are exchanged with Monte Carlo based versions. This is facilitated by the component software design of ATHENA that allows dynamic library loading at execution time. Technically it is realised in a way that both, the stochastic and the random number driven material effects integrator extend the same interface definition, while being part of different libraries. Wherever feasible FATRAS uses modules from Geant4, but several exceptions are necessary to this.
Currently the FATRAS simulation is validated against the full Geant4 simulation for the current ATLAS layout, in order to optimise the agreement, estimate calibration parameters or at least understand the remaining differences between the two simulation strategies. Summarising this effort would go far beyond the scope of this document and has to be omitted in order to be described elsewhere. FATRAS is based on the reconstruction geometry and the existence of such a geometry description is indeed the single requirement for FATRAS to be executed. Thus, the integration of the upgrade Geant4 simulation into the ATHENA framework and the additional requirement for an upgrade reconstruction geometry for track reconstruction studies yielded a working FATRAS version at no additional cost of any kind. Figure 3 shows a comparison of reconstructed hits on tracks simulated with the full Geant4 simulation and FATRAS in a concept upgrade layout with 4 pixel barrel layers and 5 double-sensor Silicon strip layers.

Custom Geometry Building with FATRAS
In addition to running FATRAS in parallel to the Geant4 simulation, there exists also a convenient way for detector geometry design. Since FATRAS and Geant4 can be easily compared due to the shared reconstruction algorithms, the custom geometry building capabilities of FATRAS allow for outsourcing some of the simulation from the time-consuming Geant4 simulation to FATRAS. Ideally, the detector design including layer positions and module specifications can be iterated using FATRAS, while only few final layout candidates need to be processed by the time-consuming full simulation bulk production. A dedicated python description for sensors, modules, layers and volumes has been established that can be freely used to modify detector parameters. A full python detector description can be included in the FATRAS simulation job steering that is translated into ATHENA algorithms and replaces the GeoModel based TrackingGeometry creation used in full simulation. The python setup also includes an automated creation of the XML based channel identification system used in ATLAS. It also comes with a simple displaying module using the ROOT OpenGL viewer and the PyROOT interface [15]. Figure 4 shows a screenshot of a pixel detector in the design phase and an associated generated dictionary XML file.
The custom geometry building modules allow also to implement custom material maps that can be defined for the several module or layer objects. This should allow fast estimates of changed material budgets in the upgraded tracking detector when moving detector components or changing the individual material constituents.  Figure 4. Screenshot of a step in the custom geometry building using FATRAS. A python detector description is loaded at ATHENA startup and is then translated into a reconstruction geometry description that is used in FA-TRAS.

CPU Performance
CPU performance is a considerable aspect for the full detector simulation. The full Monte Carlo detector simulation and digitisation are the dominating contributors to the overall CPU consumption of the event processing at LHC design luminosity. At high pileup scenarios, however, the fraction of time needed by the reconstruction modules becomes equally large. The reason for this in mainly the huge number of track candidates caused by the high combinatorics of potential hit patterns. However, event reconstruction has not always to be performed for all purposes, e.g. not when studying detector overlap, hermiticity or hit occupancies. In these cases, a fast simulation would certainly be comfortable during the detector design phase with changing layout setups. The simulation time in FATRAS is well under control and stays below one minute per event even for 400 embedded pileup events, Fig. 5 shows the CPU time spent on an Intel R Xeon R CPU 5150 (2.66 GHz) processor.

Conclusion
We have presented a combined strategy of full and fast simulation using Geant4 and FATRAS for the Monte Carlo simulation of ATLAS inner tracker upgrade layouts. While the usage of a full but time consuming Monte Carlo simulation with the most detailed implementation of both detector effects and physics processes is inevitable to give final answers and to conclude on certain detector layout elements, an alternative fast simulation technique can be used to get an initial estimate of design parameters in a fast feedback cycle. Using a shared reconstruction program for both approaches and an ongoing validation of FATRAS against results obtained with Geant4 eases the comparison and puts confidence in the results obtained with the fast simulation.