Difference between revisions of "Track matching to BCAL & danahddm"
From GlueXWiki
| (7 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | 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: |
| − | // hits can be skipped | + | |
| + | <pre> | ||
| + | // 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;</ | + | if (fabs(tproj-bcal_showers[k]->t)>OUT_OF_TIME_CUT) continue; |
| + | </pre> | ||
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! | + | With tproj=-999, no track passes the timing cut. '''No tracks are ever matched to BCAL clusters!''' |
Why is this? | Why is this? | ||
| Line 30: | Line 37: | ||
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. | ||
Latest revision as of 18:54, 16 February 2012
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?
