Track matching to BCAL & danahddm
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?