Skip to content

Dev#415

Merged
alkemyst merged 632 commits intomasterfrom
dev
Dec 18, 2017
Merged

Dev#415
alkemyst merged 632 commits intomasterfrom
dev

Conversation

@alkemyst
Copy link
Contributor

No description provided.

ghugo83 and others added 30 commits June 22, 2017 14:31
…i. This was bound to have disks and their cabling entirely identical on both -Z and +Z sides. Now, Phi-nonants boundaries are ligned-up all along Z. As a result, disks will be different whetehr they are placed on (-Z) and (+Z) sides.
… for Phi = 0, so that disks are exactly identical oin both sides along a Z axis.
… default, boundaries are the ones for TDR layout.
Full handling of a Timing Barrel Layer with tkLayout: from cfg files to XML export for full simulation
ghugo83 and others added 29 commits November 27, 2017 13:45
…ement::checkTrackHits has the following issues in devLite: some hits positions are wrongly computed and are actually not inside the inactive volume, hugely increasing the total crossed MB (and hence worsening the resolution). + Case of a tube or disk crossed in the non-trivial sense not always taken into account. Created new and fully debugged InactiveElement::checkTrackHits method (should be backported to devLitegit log).
…s region is a gaussian Gaus(0, 70). Though, the code was only taking into consideration the sensors such that sensor.maxZ() > 0.
…, because the local resolution is assigned to it. It cannot be stored directly within the track, since a given module will be hit by several tracks, and we want the information at the module level!
…s) plot in OT material tab: was showing OT + IT result instead of OT result only. This is not really an issue in itself, but since there is a OT, IT, and Total material tabs, things should follow that logic.
…fied directly in SimParms, instead of hardcoded in Analysis code. NB 1: rPhiErrorCollider has never been used for defining the origin of the track! And the analysis code is not adapted consequently. One assumes that the track is always on (Z) axis. NB 2: Would be more elegant to have a Shape of luminous region class, where one could specify the parameters of interest relevant for each supported distribution.
Important: Bug fixes affecting tracking resolution + Shape of luminous region for resolution studies
IMPORTANT: Bug fix in trigger efficiency results
Pattern reco studies: Switch from IP = (0,0,0) to uniform luminous region from -70 mm to 70 mm.
Merge PR#332 from Zbynek: renaming HitNew -> Hit, TrackNew -> Track
Shape of luminous region directly specified in SimParms
…computed on the Outer Tracker layouts for which it is designed.
With option 'all', the cabling map is now automatically computed on the layouts for which it is designed
@alkemyst alkemyst merged commit aa09bc7 into master Dec 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants