Track matching to BCAL & danahddm
I noticed that when using hddm files output from the danahddm plugins, charged tracks are never associated with BCAL showers, though this feature works fine when not using 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
With tproj=-999, no track passes the timing cut. 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?