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

Revision as of 18:41, 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?