90 likes | 199 Views
VEPIX53: Plans on hit generation inside the framework. Sara Marconi. OUTLINE. Classes of hits to be generated M ain parameters Statistics on what is generated Available options Priority “to do” list. Class of hits to be generated: Introduction.
E N D
VEPIX53: Plans on hit generation inside the framework • Sara Marconi
OUTLINE • Classes of hits to be generated • Main parameters • Statistics on what is generated • Available options • Priority “to do” list
Class of hits to be generated: Introduction • Per each BX different kinds of hits to be generated: • Single tracks • randomly distributed in the pixel chip • variable number of hit pixels per cluster • at a given angle • Loopers (random hits) • low energy particles • single track crossing at 90° • Jets • multiple clusters concentrated in a given area • can be seen as multiple tracks • clusters can be overlapping • Monsters • very “long” tracks • Noise hits • not correlated with tracks • Definition of “hit”? • time (BX - with possibly random delay to be added) • random amplitude (charge or TOT) Sensor Interaction point
Class of hits to be generated: Single tracks • Single tracks: • Parameters fixed for a sequence of n bunch crossing cycles: • Track rate (Hz/cm2) • to be converted in number of clusters per pixel chip per BX given the pixel chip area • Position on the detector (given as track angle 0°-90°) • to be converted in “length of the cluster” (number of pixels from 1x1 to 1xN) • given a certain sensor thickness and the pixel dimension in the direction of the angle • Level of charge sharing: • possible parameter (0,+1,+2) • to define how many pixels surrounding the 1x1-1xN central ones are interested • plus additional parameter to randomize how many are actually hit inside the envelope sensor thickness
Class of hits to be generated: Loopers • Loopers: • Parameters fixed for a sequence of n bunch crossing cycles: • Looperrate (Hz/cm2) • to be converted in number of loopers per pixel chip per BX given the pixel chip area • if zero, they should be disabled • it could call the same routine used for single track generation • forcing 1x1 central hits (assuming 90° track angle) • using defined parameters for • charge sharing sensor thickness
Class of hits to be generated: Jets • Jets: • Parameters fixed for a sequence of n bunch crossing cycles: • Jet rate (Hz/cm2) • to be converted in number of jets per pixel chip per BX given the pixel chip area • if zero, they should be disabled • Number of tracks per jet • impose a certain distribution (e.g. poisson with a certain mean; certain min-max range) • Size of the “jet area” (in cm2 or num of pixels) • where central addresses of tracks are concentrated • at the generation level overlapping cluster are summed up (to be pointed out: how to merge hits in pixel?) • For each track: it could call the same routine used for single track generation • choosing central address within the defined “jet area” • using defined parameters for: • position on the detector • level of charge sharing
Class of hits to be generated: Monsters • Monsters: • Parameters fixed for a sequence of n bunch crossing cycles: • Monster rate (Hz/cm2) • to be converted in number of monsters per pixel chip per BX given the pixel chip area • if zero, they should be disabled • Size of the monster • To be kept separated from generation of single tracks • Cluster dimension: 1xN with N = “Size of the monster” • Using same parameter for: • level of charge sharing
Statistical analysis on what is generated Possible options for statistical analysis: • Writing (each BX) to a file only generated hits • useful for debugging • to be read by Matlab/ROOT for statistical analysis • file format to be defined • Analysis (partially) within the framework: • using multidimensional arrays to accumulate histograms • how to read the stored info: • let ROOT access during the simulation the memory address where they are written (if possible) • write them to an output file every m BX cycles (to improve performances) • Analysis in the framework using C# for graphics • need to interface SV with C# • to be investigated • C# expertise needed
Priority “to do” list What to do next (in parallel): • Classes of hits to be generated: • refine single track generation using the agreed parameters • proceed incrementally with: • Loopers • Jets • Monsters • Noise hits • Statistics on what is generated • Dumping into file • With initial statistical analysis of generated data with Matlab (if me) or ROOT (for people who know it) • Analysis partially into the framework and/or interfacing with C# • Choice mainly dependent on who is going to work on it