Difference between revisions of "Track matching to BCAL & danahddm"
From GlueXWiki
| Line 12: | Line 12: | ||
tproj is an argument passed to the function. MatchToBCAL is called in DChargedTrackHypothesis_factory: | tproj is an argument passed to the function. MatchToBCAL is called in DChargedTrackHypothesis_factory: | ||
| − | < | + | <pre> |
| + | // Initialize projected time to estimate from track | ||
locProjectedTime = locTrackTimeBased->t0(); | locProjectedTime = locTrackTimeBased->t0(); | ||
| − | dPIDAlgorithm->MatchToBCAL( ... , locProjectedTime, ... )</ | + | dPIDAlgorithm->MatchToBCAL( ... , locProjectedTime, ... ) |
| + | </pre> | ||
The problem is that DTrackTimeBased's from a danahddm produced file always have a t0 of -999. | The problem is that DTrackTimeBased's from a danahddm produced file always have a t0 of -999. | ||
| − | < | + | <pre> |
| + | DTrackTimeBased: | ||
q: x(cm): y(cm): z(cm): E(GeV): t(ns): p(GeV/c): theta(deg): phi(deg): candidate: wirebased: chisq: Ndof: FOM: | 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 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 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.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 </ | + | +1 -1.1 -0.4 104.1 4.539 -999.000 4.441 84.949 108.633 7 0 17.254515 1 0.000033 |
| + | </pre> | ||
| − | No tracks are ever matched to BCAL clusters! | + | '''No tracks are ever matched to BCAL clusters!''' |
Why is this? | Why is this? | ||
| Line 31: | Line 35: | ||
t is saved in JEventProcessor_danahddm::Add_DTrackTimeBased() | t is saved in JEventProcessor_danahddm::Add_DTrackTimeBased() | ||
| − | < | + | <pre> |
| + | tbt_hddm->origin->t = 0.0; | ||
tbt_hddm->origin->vx = pos.x(); | tbt_hddm->origin->vx = pos.x(); | ||
tbt_hddm->origin->vy = pos.y(); | tbt_hddm->origin->vy = pos.y(); | ||
| − | tbt_hddm->origin->vz = pos.z();</ | + | tbt_hddm->origin->vz = pos.z(); |
| + | </pre> | ||
in DEventSourceHDDM::Extract_DTrackTimeBased(), t is never restored, so this remains at the default value of -999. | in DEventSourceHDDM::Extract_DTrackTimeBased(), t is never restored, so this remains at the default value of -999. | ||
Revision as of 18:42, 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?
