Track matching to BCAL & danahddm

From GlueXWiki
Jump to: navigation, search

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?