Transcript Slides - Agenda INFN

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
12.13.979817MeVMeV
Ev:: 978 X-Z planes
12.12.266576MeVMeV
14.15.562423MeVMeV
5.10.17.347784307MeVMeV
18.21.428165MeVMeV
24.29.331999MeVMeV
76.964 MeV
0.0.320567MeVMeV 0.0.234598MeVMeV 0.0.254298MeVMeV 0.0.321096MeVMeV 0.0.623138MeVMeV 0.0.290352MeVMeV 9.557 MeV 53.869 MeV
2.2.2.2.564516256992MeVMeVMeVMeV 2.2.2.2.468846414586MeVMeVMeVMeV 2.2.468581MeVMeV 2.3.804858MeVMeV
2.2.861760MeVMeV 2.2.878536MeVMeV 2.2.2.3.786142087907MeVMeVMeVMeV 3.3.369035MeVMeV
2.2.762930MeVMeV 72.134.51.1546.2627MeV1748931.MeVMeVMeV90.480MeV12 MeV
0.238 MeV
0.1120.MeV032415593025224470.MeV006 MeV
0.267 MeV
12.13.979817MeVMeV
Ev:: 978 Y-Z planes
12.12.266576MeVMeV
14.15.562423MeVMeV
5.10.17.347784307MeVMeV
18.21.428165MeVMeV
24.29.331999MeVMeV
76.964 MeV
0.0.320567MeVMeV 0.0.234598MeVMeV 0.0.254298MeVMeV 0.0.321096MeVMeV
0.0.623138MeVMeV 0.0.290352MeVMeV 9.557 MeV
53.869 MeV
2.2.652592MeVMeV 2.2.684186MeVMeV
2.2.541669MeVMeV 2.2.484645MeVMeV 2.2.468581MeVMeV 2.3.804858MeVMeV
2.
3.
8
1
08
07
MeV
MeV
2.
2.
8
61
7
60
MeV
MeV
2.2.878536MeVMeV 2.2.764279MeVMeV 3.3.369035MeVMeV 72.51.1546.227MeV489MeVMeV
2.2.762930MeVMeV 134.61731.MeV948 MeV
0.238 MeV
0.112 MeV
0.006 MeV
0.03241550.93025224470MeV12 MeV
0.267 MeV
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
Beam
PMMA
Target
p
Plastic
Scintillator for
TOF
measurement
Drift Chamber
LYSO Crystal
16O
-15
-10
Exp. Data
MC
-5
0
5
10
15 20
Z (cm)
10 cm
B.P. position
0.16
0.14
0.12
0.1
0.08
0.06
0.04
0.02
0
-20
@ 210 MeV/u on PMMA
Longitudinal emission profile of protons
emitted at 90o.
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
Start
counter
Beam Monitor
(Drift chamber)
Target
3rd Tracker
(Drift chamber)
Calorimeter
Beam
1st
pix
tracker
Input specifications:
•
•
•
•
Magnet 1
Magnet 2
•
•
•
Dimensions
Distances
Materials
Magnetic field intensity •
(map)
Beam particle & energy
Physics options
cut-offs for production &
transport
etc. etc.
Scintillator
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...
1)Groups developing detector parts have the
responsibility to provide correct specifications
2)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
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 (deltarays etc.): CPU and output size will increase significantly
Building the MC Output
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
Output from
MC: Txt file
1st Step
ROOT file
with Tree structure
2nd Step
Tree
Branches
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
Crossing structure
Particle structure
Information about the particle that cross
different regions of the setup (target, air,
detectors, etc)
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









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
nDET = 2
deDET(2) = Sum of energy releases by that “particle”
in DET
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:
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
...
Layer 1:
Combining detectors logically coupled.
See talk by A. Sarti
Mainly individual groups
team with people from different groups
Tracking in magnetic field from MIMOSA trackers + Drift chamber
Momentum measurement
Combining ΔE in scintillator and E in calo to identify Z, A,
...
Layer 2:
team with people from different groups
Global event reconstruction
matching clusters from Scint+Calo with tracks found in MIMOSA + Drift Ch.
identifying tracks originating in target
etc. etc.
An example at layer 0: the Beam
Monitor drift chamber
iso-drift time circles
Clean track reconstruction
Single track reconstruction
when ≥1 hit/plane exist
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
Identify
out-of-vertex
tracks
Get rid of
noise hits
again at layer 0: clustering in calo
n 82 MeV
n 25 MeV
n 23 meV
7Li
4He
178 MeV/n
200 MeV/n
d 188 MeV
3 p 281 MeV, 108 MeV, 37 MeV
y [cm]
2
1.5
1
0.5
0
101
101
102
102
104
105
Hits map yz - all part
103
104
105
Hits map yz - all part
103
106
106
hTotHitsMapYZ
Entries 602
Mean x 103
Mean y -0.03635
RMS x 1.553
RMS y 0.2994
107
z [cm]
hTotHitsMapYZ
Entries 602
Mean x 103
Mean y -0.03635
RMS x 1.553
RMS y 0.2994
-2
-1.5
101
-1
-0.5
102
0
0.5
103
1
]
104
1.5
[c
m
y
-0.5
-1
-1.5
-2
2
1.5
1
0.5
0
-0.5
-1
-1.5
-2
107
z [cm]
6 cm
6 cm
y [cm]
10 proton tracks in a crystal
2
105
Hits m
a
p
y
z
a
l part
106
107
z [cm]
hTotHitsM
apYZ
Entries
602
Mean x
103
Mean y
-0.03635
RMS x
1.553
R
M
S
y
0.2994
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
1) Use of graphical user interface of MC to visualize/inspect
geometry
1) 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)
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
- ...