1 / 6

C-Rack Geometry, Test Beams, and ORCA

C-Rack Geometry, Test Beams, and ORCA. Ivan D Reid Brunel University. Test-Beam C-Rack Geometry. Geometry and ancillary files are archived in the ORCA CMS system under Data/TrackerTBGeometries/CRACK ; files for Test Beam are stored under Data/TrackerTBGeometries/X5bMay2004/TOBOnly/6rod .

emory
Télécharger la présentation

C-Rack Geometry, Test Beams, and ORCA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. C-Rack Geometry, Test Beams, and ORCA Ivan D Reid Brunel University

  2. Test-Beam C-Rack Geometry • Geometry and ancillary files are archived in the ORCA CMS system under Data/TrackerTBGeometries/CRACK; files for Test Beam are stored under Data/TrackerTBGeometries/X5bMay2004/TOBOnly/6rod. • Four-rod geometries also exist in Data/TrackerTBGeometries/X5bMay2004/TOBOnly/4rod but these are not up-to-date. Edit the six-rod files to be sure of the latest features. • Changes have also been made to the naming of parts, and slight changes in the organisation, so that OSCAR simulations will properly generate interactions within the silicon: This is referred to by the OSCAR file Data/ProductionCuts/tracker.xml, which specifies the GEANT4 tracking cuts in the tracker. We must also include the line: <File name="ProductionCuts/tracker.xml" url="."/> in our main configuration.xml during the OSCAR simulation. (This unfortunately generates warning messages when it is parsed, as it refers to sensor types that we have not declared, but they are harmless). For debug purposes, it may sometimes be convenient to leave this line out, since this then switches off most secondary interactions, which might make tracking studies etc. simpler. But for final comparison with data, it should be included. The outermost box (which surrounds the TRAK box) must be called OCMS, otherwise it is impossible for OSCAR to simulate a B-field. (Not relevant at present, but would be needed if ever we place the TOB/TEC in a field.). Also, during the OSCAR simulation, the main configuration .xml file must include the line : <File name="PropagationInField/FieldParameters.xml" url="."/>. • Messages generated by these extra lines during reconstruction may be ignored.

  3. Gluing bug solved • The r-f and stereo detectors were not being “glued” together properly because they are associated via the angle f in the XY-plane. Since all our detectors are centred on the Y-axis, they all have f = ±p/2! • Inelegant solution was to hack (unfortunately!) DetUnitGluer.cc. • “Matched” hits in the DS rods are now much more reliably found, to define the Y as well as the X positions in those planes. • Reliable reconstruction requires proper layer grouping in BarrelRingFinder – set the ClusterResolution parameter to 1.1 cm.

  4. A Clue to the Distribution of RecTrack Y Positions in PG MC • Cutoffs in sucessful track reconstruction positions correspond to the extents of the detectors! • This suggests that the use of “rings” in the detector geometry is responsible for the effect.

  5. Different Code Paths • The TestBeam and MonteCarlo reconstruction codes follow different routes, since the TestBeam events are not despatched via G3Observer. In particular it is noted that the TestBeam code passes through BarrelRingFinder code once, but MonteCarlo passes through twice: BarrelRingFinder:: Dividing Z into 1/2 cm BarrelRingFinder:: Clustering resolution 1.1 cm. Glued TB M (6.05454e-15,-44.3014,117.5) S (6.00556e-15,-44.3014,117.9) Glued TB M (5.0541e-15,-27.5624,116.9) S (5.07859e-15,-27.5624,116.5) Glued TB M (3.87486e-15,-8.7034,117.5) S (3.82588e-15,-8.7034,117.9) Glued TB M (2.83352e-15,8.7036,116.9) S (2.85801e-15,8.7036,116.5) Glued TB M (1.66641e-15,27.3646,117.5) S (1.61742e-15,27.3646,117.9) Glued TB M (5.83611e-16,45.4486,116.9) S (6.08103e-16,45.4486,116.5) ***COMMON*** DetRing Warning: not periodic. ndets=6 Dets(r,phi,pos): (44.3014,-1.5708, (6.05454e-15,-44.3014,117.5) ) Dets(r,phi,pos): (27.5624,-1.5708, (5.0541e-15,-27.5624,116.9) ) Dets(r,phi,pos): (8.7034,-1.5708, (3.87486e-15,-8.7034,117.5) ) Dets(r,phi,pos): (8.7036,1.5708, (2.83352e-15,8.7036,116.9) ) Dets(r,phi,pos): (27.3646,1.5708, (1.66641e-15,27.3646,117.5) ) Dets(r,phi,pos): (45.4486,1.5708, (5.83611e-16,45.4486,116.9) ) ... BarrelRingFinder:: Dividing Z into 1/2 cm BarrelRingFinder:: Clustering resolution 1.1 cm. Glued TB M (3.87486e-15,-8.7034,117.5) S (3.82588e-15,-8.7034,117.9) Glued TB M (2.83352e-15,8.7036,116.9) S (2.85801e-15,8.7036,116.5) ***MonteCarlo Only*** DetRing Warning: not periodic. ndets=2 Dets(r,phi,pos): (8.7034,-1.5708, (3.87486e-15,-8.7034,117.5) ) Dets(r,phi,pos): (8.7036,1.5708, (2.83352e-15,8.7036,116.9) )...

  6. Clustering in f • It seems the first part, where detectors are correctly grouped into the layers, occurs during the first call to FullTracker::instance()->allLayers() • The second call in the MonteCarlo code comes in generating the Numbering Scheme, where the DetUnits are clusterised in f and then passed to BarrelRingFinder. The “rings” found here correspond to detector slices through the C-Rack. • I suspect that this is a root cause of the reconstruction proceeding in these “rings” and therefore suspect that this effect will not affect TestBeam reconstruction where this clustering is not done. This remains to be verified...

More Related