Difference between revisions of "Track matching to BCAL & danahddm"

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?