ORCA CMS Goto: Class list(annot.) Class members File list File members Everything Release notes Dependencies BuildFiles .orcarc Parameters RecAlgos ConfigAlgos
Goto: ORCA Calorimetry CommonDet CommonReco Examples HLT Jets Muon MuonReco Tracker TrackerReco Trigger Vertex ElectronPhoton
Goto: bTauAnalysis eGammaAnalysis JetMetAnalysis MuonAnalysis StandardModel HiggsAnalysis HeavyIonAnalysis

TrackerdomainTracker_relnotes600

Release Notes for Tracker ORCA_6_0_0

In this release the "old" Tracker subsystem, which contained all the software used  by the PRS Btau group, has bween splitted in different subsystems. Namely, the "new" Tracker contains only code for: All the code relevant for reconstruction, from clusterization on, has been moved to TrackerReco.

Geometry construction

A new mechanism to construct a Tracker geometry has been implemented. It uses auto-registration of a Builder via a PkBuilder statement, and allows to build all the Tracker geometry on demand after the first request (typically a call to FullTracker::instance()->dets()).
For the moment the only builder released is building the geometry using the cmsim title file; implementations using ascii files or Geant4 geometries are in the way.
This change is completely transparent to the standard user.

Hit Formatting & Loading

The ReadOut unit schema for  SimHits is completely changed. Instead of having a single ROU attached to the whole Tracker ("THupto08"), now each subdetector has its own Unit:

Moreover, each of them is actually not the name of the ROU, but the name of the master ROU to which we have attached 2 different ROUs. In the first of these we load only the Hits with ToF smaller than a certain threshold (12.06 ns x 3), in the other those with bigger Tof. So we have, for example, This is very useful when digitizing events with Pile-up: since the tracker electronic has an integration width of 12 ns for the strip and a window of 25 ns for the pixels, we can avoid loading the container which cannot produce any signal in the tracker and thus save time.

Digitization

The digitization framework has deeply changed in ORCA 6. When linking libraries containing a digitizer code, a special builder class registers the digitizer to the framework assign a name (string to it). When the digitizer is requested from the user or from the clusterizer, a special factory is able to return the right digitizer based on a configurable in .orcarc:
   TkSiStripDigitizer:DigitizerName
If a digitizer with that name (or the default one if the configurable is not present) has registered, it is returned; otherwise an exception is thrown.
The same mechanism holds for clusterization, but in this case only the factory is in Tracker, while the concrete digitizers are in TrackerReco.

Moreover, the SiStripDigitizer class has been divided into a number of smaller classes to allow separate studies about charge dividing, drift and so on. Tha same process is ongoing for the Pixel Digitizer.

A new default value for the Charge sharing has been defined for the MicroStrips: the central strips gets 76% of the charge, while the two closest neighbours get 12% each.

Access to the topology of a DetType

Since this version the creation of the Topologies is strictly on demand, and can be done only when the global action (make digis or read digis)  has been already clarified.
This means for example that This will stay like this till when the Tracker geometry / DetTypes will be  subject to changes.

Links to previous release notes:



Tommaso Boccali


Generated at Thu Nov 25 17:12:59 2004 for ORCA by doxygen1.2.6 written by Dimitri van Heesch, © 1997-2001