G. Battistoni, I. Mattei, S. Muraro, V. Patera, A. Sarti, S. Valle FOOT Simulation: Organization and To Do List in view of Design Optimization and Reconstruction Software Development G. Battistoni, I. Mattei, S. Muraro, V. Patera, A. Sarti, S. Valle

Aim of the presentation For many months simulation will be the way to: optimize the design and identify possible criticalities in the layout learn how to reconstruct events, combining together signals from individual detector parts understand the expected performances We need to involve people from all groups and put everyone in conditions of processing simulated data in order to: arrive to the final/detailed design of the apparatus develop reconstruction code for each detector element develop overall reconstruction and data analysis procedure ➜ Therefore we cannot limit this presentation just to simulation

MC code Provisional MC setup developed in the last 12 months (Rm-Mi) Evolved from the experience at FIRST, test beam experiments at GSI, CNAO, HIT

Example: analysis of charged particle data taken at Heidelberg with He, C and O beams PMMA Target Plastic Scintillator for TOF measurement p Drift Chamber LYSO Crystal

16O @ 210 MeV/u on PMMA Longitudinal emission profile of protons emitted at 90o. Exp. Data MC 10 cm B.P. position

FOOT MC code now Based on FLUKA MC code (http://www.fluka.org) Default architecture: Linux (RedHat, Fedora, Scientific Linux, CentOS, Ubuntu, other distributions) Beta version for MacOSX (reserved to developers for the moment) Our development: event by event output built from “user routines” of FLUKA designed to provide detector response and a lot of infos about “MC truth” (particle identity, history of particles, etc.) Trade-off between size of output files and no. of info which are saved Two-step approach: 1) basic event generation (FLUKA environment) 2) postprocessing of events (ROOT Tree generation and elaboration)

FOOT simulation today: FLUKA geometry & materials 2nd pix tracker 3rd Tracker (Drift chamber) Beam Monitor (Drift chamber) Calorimeter Start counter Target Beam Magnet 1 1st pix tracker Scintillator Magnet 2 Input specifications: Beam particle & energy Dimensions Physics options Distances cut-offs for production & transport Materials Magnetic field intensity (map) etc. etc. Warning: At this time we have not yet considered the ECC setup

Evolving the design from now on Notice: At present all dimensions, distances, materials are just the product of reasonable guess. No real details at all... Groups developing detector parts have the responsibility to provide correct specifications The layout of the apparatus has to be revised. CDR: we have to agree and freeze a 1st version, to be updated when the optimization work will point out the need of introducing changes. Who/When/How

Silicon Pixel Detector Just an example: Silicon Pixel Detector Target Silicon Pixel Detector All pixel detectors at the moment are totally idealized: “details” like support materials/boards are important! (MS, extra-fragmentation etc.)

Some numbers Simulation of 12C @ 200 MeV/u <CPU time>/event ~ 1.34 10-2 s/event on a single CPU Intel(R) Core(TM) i7-3770 @ 3.40GHz Event by Event output (txt file): ~ 0.5 Gbyte/106 primaries (selecting events with inelastic interaction in target) Warning: At this time we ~neglected low energy electrons (delta-rays etc.): CPU and output size will increase significantly

Building the MC Output 1st Step 2nd Step In the past we used to produce directly a ROOT file from MC. Still possible but not straightforward portability across different architectures/compilers/etc. Present choice: MC outputs Txt files contains information about all the particles and interaction simulated. A simple and portable code reads these txt’s and outputs ROOT files 1st Step with Tree structure Output from MC: Txt file Tree Branches 2nd Step A code to readout simulation, perform post-processing and analysis of ROOT files is made available to the whole collaboration allowing to participate even without a specific preparation about MC technicalities

Information Available after 1st Step of Simulation Particle structure Information of all the produced particles num_event = FLUKA events number nump = number of particles produced idpa = index in the part common of the particle parent icha = charge iba = barionic number idead = how (interaction) the particle dies jpa = FLUKA code for the particle igen = how (interaction) the particle is generated vxi, vyi, vzi = production position of the particle vxf, vyf, vzf = final position of the particle px, py, pz = production momentum of the particle amass = particle mass tempo = production time of the particle tof = total tof of the particle trlen = track lenght of the particle Crossing structure Information about the particle that cross different regions of the setup (target, air, detectors, etc) ncross = crossing number idcross = position of the particle responsible of the crossing in the particle block nregcross = region in which the part enters nregoldcross = region from which the particle escapes xcross, ycross, zcross = position of the crossing pxcross, pycross, pzcross = momentum of the crossing particle mcross = mass of the crossing particle chcross = charge of the crossing particle tcross = time of the crossing particle Detectors structure Information of the particle-detector interactions nDET = number of energy release in the detector DET idDET = position of the particle responsible of the release in the particle block icolDET, irowDET = in pixelated detectors column and row where the energy release occurs xinDET, yinDET, zinDET, xoutDET, youtDET, zoutDET = initial and final position of energy release pxinDET, pyinDET, pzinDET, pxoutDET, pyoutDET, pzoutDET = initial and final momentum of the energy release deDET = energy release timDET = initial time of the energy release

idDET(2)-1 = pointer to the particle in Particle Structure that originated hit=2 to access all infos (id, quantum numbers + kinematics) about that particle deDET(2) = Sum of energy releases by that “particle” in DET nDET = 2 xinDET(2), yinDET(2), zinDET(2) xoutDET(2), youtDET(2), zoutDET(2) DET xinDET(1), yinDET(1), zinDET(1) xoutDET(1), youtDET(1), zoutDET(1) nDET = 1 deDET(1) = Sum of energy releases by that “particle” in DET idDET(1)-1 = pointer to the particle in Particle Structure that originated hit=1 to access all infos (id, quantum numbers + kinematics) about that particle

About the Two-Step approach At present we have in 1st step simulation ideal/perfect detectors. Beyond actual dimensions/materials/etc. we need smearing/resolutions or other parameters like photostatistics, cross-talk probability, noise, etc. Again to be provided by detector developers! All those things can be inserted at 2nd step (post-processing) level when reading ROOT files from 1st MC step. Pro’s: flexibility Con’s: may introduce fluctuations without repeatability of random numbers (but it should be a minor problem!)

Possible organization of work 1st Step: Preparing input files, compiling/debugging code, running production etc. requires a specific technical preparation on the MC code. Not particularly exciting, general service work It’s advisable that this is managed by a limited group of experts. However: if there are people who wishes to learn about this and contribute is more than welcome!! feedback is of course necessary 2nd Step: This is the place where real development and physics understanding takes place! All groups must learn to use it and contribute. Only a limited knowledge of MC technicalities is needed: coordinate system and units particle numbering (for instance in FLUKA proton = 1, photon = 7, etc.) ... Of course Readout/Analysis code maintained, distributed and documented at central level again by few experts

Towards FOOT reconstruction software Layered organization: See talk by A. Sarti Layer 0: Reconstruction code for individual detector systems. 1st MIMOSA tracker: track finding, vertex finding, etc. 2nd MIMOSA tracker: track finding, ... Drift chamber: track finding and reconstruction ... Mainly individual groups Layer 1: Combining detectors logically coupled. Tracking in magnetic field from MIMOSA trackers + Drift chamber Momentum measurement Combining ΔE in scintillator and E in calo to identify Z, A, ... team with people from different groups Layer 2: Global event reconstruction matching clusters from Scint+Calo with tracks found in MIMOSA + Drift Ch. identifying tracks originating in target etc. etc. team with people from different groups

An example at layer 0: the Beam Monitor drift chamber iso-drift time circles Single track reconstruction when ≥1 hit/plane exist Clean track reconstruction What about multiple tracks? WE NEED TO IMPLEMENT TIME-SPACE DEPENDENCE IN SIMULATION ?

An examples at layer 0: the 1st tracker Identify tracks Identify vertex Get rid of noise hits Identify out-of-vertex tracks

again at layer 0: clustering in calo n 82 MeV n 25 MeV n 23 meV 7Li 178 MeV/n 4He 200 MeV/n d 188 MeV 3 p 281 MeV, 108 MeV, 37 MeV

10 proton tracks in a crystal 6 cm 6 cm 6 cm

At a next layer: is there a (rough) match between tracker and beam monitor info?

At a next layer: matching pieces of the same track and measure p (➜ Kalman filter reconstruction...)

At a next layer: algorithm to put together scint + calo hits

By the way: how do we manage these cases?

At a next layer: full track definition

To be done as general service 1st Step: Produce the geometry of a “certified” setup for 1st version. Infos from all experts of detector parts are needed. Iterations will be necessary. Define some parameters. Only criticality at present could be represented by e- cutoffs (those affecting more CPU and output size while tracking particles in MC) 2nd Step: Deliver and document readout code for analysis and post processing. Contribution from collaboration (reconstruction algorithms etc.) will be inserted regularly in updates A “Configuration” setup in common between MC developers and Reconstruction developers has to be managed at some level (Alessio may have some ideas...)

Other items of general interest An event display is necessary: - can be done again for 2nd Step software Example from FIRST experiment

know-how of 1st step that could be useful for each group Use of graphical user interface of MC to visualize/inspect geometry Running single detectors studies: - this can be easily performed without touching the general layout, routines and output structure. Single particles/nuclei can be shot starting from any point just by editing the input file to MC (ASCII file editing or by means of the graphical user interface) In case it can be easily managed also at central level If there are collaborators interested to learn we can organize a few-days course at some time

Conclusions 1 Each detector team has to start specific development of specific reconstruction software A small team for Step 1 exists but can/must be enlarged. We need to build a larger software team, mainly in Step 2, possibly including competence from detector teams Software development must start now and this can be done using simulated data A “course” can be organized soon after summer holidays Before everything else: we need to deliver a version 1.0 as soon as possible adjusting and fixing sizes/distances/... etc.: a team should take care of this asap. A parallel setup to include ECC has to started All this can be inserted into a more elaborated framework (see Alessio’s talk) Also: an optimization strategy of the design has to be conceived

Conclusions 2 Short summary of first homework for groups developing detectors: provide detailed infos about structure, performance, resolution etc. learn to manage Output readout & analysis code develop specific reconstruction code Other items to be organized: Storage of simulated events and access to them ...