Difference between revisions of "Track matching to BCAL & danahddm"
(Created page with "in the DParticleID::MatchToBCAL( ... ) function we have the following comment and line: <code>// NOTE: an initial guess for tproj is expected as input so that out-of-time //...") |
|||
Line 16: | Line 16: | ||
The problem is that DTrackTimeBased's from a danahddm produced file always have a t0 of -999. | The problem is that DTrackTimeBased's from a danahddm produced file always have a t0 of -999. | ||
− | <code>DTrackTimeBased: | + | <code><nowiki>DTrackTimeBased: |
q: x(cm): y(cm): z(cm): E(GeV): t(ns): p(GeV/c): theta(deg): phi(deg): candidate: wirebased: chisq: Ndof: FOM: | q: x(cm): y(cm): z(cm): E(GeV): t(ns): p(GeV/c): theta(deg): phi(deg): candidate: wirebased: chisq: Ndof: FOM: | ||
------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | ||
Line 22: | Line 22: | ||
+1 3.1 -0.8 36.5 1.064 -999.000 0.502 39.844 -104.416 1 477060304 216.797516 4 0.000000 | +1 3.1 -0.8 36.5 1.064 -999.000 0.502 39.844 -104.416 1 477060304 216.797516 4 0.000000 | ||
+1 -1.1 -0.4 104.1 4.443 -999.000 4.440 84.951 108.633 7 478698608 17.216434 1 0.000033 | +1 -1.1 -0.4 104.1 4.443 -999.000 4.440 84.951 108.633 7 478698608 17.216434 1 0.000033 | ||
− | +1 -1.1 -0.4 104.1 4.539 -999.000 4.441 84.949 108.633 7 0 17.254515 1 0.000033 </code> | + | +1 -1.1 -0.4 104.1 4.539 -999.000 4.441 84.949 108.633 7 0 17.254515 1 0.000033 </nowiki></code> |
No tracks are ever matched to BCAL clusters! | No tracks are ever matched to BCAL clusters! |
Revision as of 18:34, 16 February 2012
in the DParticleID::MatchToBCAL( ... ) function we have the following comment and line:
// NOTE: an initial guess for tproj is expected as input so that out-of-time
// hits can be skipped
[...]
if (fabs(tproj-bcal_showers[k]->t)>OUT_OF_TIME_CUT) continue;
tproj is an argument passed to the function. MatchToBCAL is called in DChargedTrackHypothesis_factory:
// Initialize projected time to estimate from track
locProjectedTime = locTrackTimeBased->t0(); dPIDAlgorithm->MatchToBCAL( ... , locProjectedTime, ... )
The problem is that DTrackTimeBased's from a danahddm produced file always have a t0 of -999.
DTrackTimeBased:
q: x(cm): y(cm): z(cm): E(GeV): t(ns): p(GeV/c): theta(deg): phi(deg): candidate: wirebased: chisq: Ndof: FOM:
------------------------------------------------------------------------------------------------------------------------------
+1 0.0 -0.0 69.4 0.517 -999.000 0.498 45.782 -98.333 1 1852268877 27.647846 23 0.229392
+1 3.1 -0.8 36.5 1.064 -999.000 0.502 39.844 -104.416 1 477060304 216.797516 4 0.000000
+1 -1.1 -0.4 104.1 4.443 -999.000 4.440 84.951 108.633 7 478698608 17.216434 1 0.000033
+1 -1.1 -0.4 104.1 4.539 -999.000 4.441 84.949 108.633 7 0 17.254515 1 0.000033
No tracks are ever matched to BCAL clusters!
Why is this?
t is saved in JEventProcessor_danahddm::Add_DTrackTimeBased()
tbt_hddm->origin->t = 0.0;
tbt_hddm->origin->vx = pos.x(); tbt_hddm->origin->vy = pos.y(); tbt_hddm->origin->vz = pos.z();
in DEventSourceHDDM::Extract_DTrackTimeBased(), t is never restored, so this remains at the default value of -999.
This is probably wrong...
Why is tbt_hddm->origin->t initialized with 0, rather than the t0 from the DTrackTimeBased?