Skip to content

Shape of luminous region directly specified in SimParms #410

Merged
alkemyst merged 30 commits intotkLayout:dev_gabiefrom
ghugo83:merge_simparm
Dec 8, 2017
Merged

Shape of luminous region directly specified in SimParms #410
alkemyst merged 30 commits intotkLayout:dev_gabiefrom
ghugo83:merge_simparm

Conversation

@ghugo83
Copy link
Contributor

@ghugo83 ghugo83 commented Dec 4, 2017

The shape of the luminous region can now be directly specified in SimParms, instead of being hardcoded in Analyzer.

Present choice is IP = (0, 0, U[-70, 70]) for all analysis, except MB analysis which uses IP = (0,0,0).

NB: Shape of luminous region for trigger studies is switched here from Gaussian(0,70) to U[-70, 70].

drasal and others added 30 commits March 23, 2017 19:10
* Added missing functionality from hit class to TrackNew & HitNew classes.
* Namely, added HitPassiveType which may be of BeamPipe, Service, Support or IP -> necessary for inactive hits in Hit class.
* Additionally, added tracking volumes variables to Hit class.
* Finally, Analyzer code adjusted to new smart pointer policy used in TrackNew class & HitNew class.
* HitNew & TrackNew classes then renamed to regular Track & Hit classes. hit.cpp & hit.hh completely removed.
Pico PR : removed HitNew and TrackNew classes from Makefile
…e in the case of an inactive element crossing the Z=0 plane. 1) Should take the negative value of eta on the left side, otherwise comparisions with track eta does not make any sense!!! 2) Should be innerRadius + rWidth instead of innerRadius. Fortunately, was unused since all inactive surfaces are cut in 2 by the Z=0 plane.
…ctive element, one should not select the Z > 0 volumes only (assuming eta >= 0). Indeed, the IP can be at Z < 0, hence volumes on (-Z) side can be hit.
…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.
@ghugo83
Copy link
Contributor Author

ghugo83 commented Dec 4, 2017

IMPORTANT NB:
The PRs to dev_gabie should be merged in the chronological order:

PR #405 (bug fixes in tracking resolution + pattern reco)
PR #407 (bug fix in trigger efficiency results)
PR #408 (extended shape of luminous region in pattern reco)
PR #409 (code style)
PR #410 (shape of luminous region in SimParms)

Each time I create a new PR, I keep the previous commits from previous PRs, so that all previous changes and fixes are incorporated, and so that there will be no merging conflict.

@alkemyst alkemyst merged commit 506ad0c into tkLayout:dev_gabie Dec 8, 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.

3 participants