1. 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

2. 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

3. 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

4. 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

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

6. 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)

7. 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

8. 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

9. 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.)

10. Some numbers Simulation of 12C @ 200 MeV/u
<CPU time>/event ~ s/event on a single CPU Intel(R) Core(TM) 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

11. 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

12. 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

13. 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

14. 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!)

15. 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

16. 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

17. 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 ?

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

19. 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

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

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

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

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

24. By the way: how do we manage these cases?

25. At a next layer: full track definition

26. 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...)

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

28. 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

29. 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

30. 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
...