[Halld-offline] Recreating tracks
pmatt at jlab.org
Thu Aug 7 16:35:08 EDT 2014
For the tracking FOM: It just copies the chisq & ndf from whatever hypothesis it copied everything else from (p3, v3, etc.). The hypothesis it copies from is determined by the DTrackTimeBased_factory_Combo::dParticleIDsToTry list. If none of the PIDs to try is available, it just takes the track with the best overall FOM (dedx + timing) and uses that one.
On Aug 7, 2014, at 2:51 PM, Matthew Shepherd wrote:
> Hi Paul,
> I'm cc'ing this one to the Hall D offline list since
> I suspect it has implications on other software systems
> like tracking.
> As you know Ryan and I have been working to both
> learn your analysis framework and cross check with
> some other high level analysis code that Ryan has
> that we used for BES and CLEO to reconstruct
> many reactions.
> We are still at the stage of trying to get consistent
> results for what we think are the same cuts running
> over the same events.
> So far the biggest issue we see (I think) is related to
> the recreation of track hypotheses for tracks that did
> not contain a hypothesis at the time the initial tracking
> is done. For example, track candidate has a proton
> fit but not a pion fit so you have a special factory that
> reconstructs the pion fit from the proton fit (not the hits)
> so it can be used in analysis.
> It seems this makes a notable difference for some
> topologies. For example, gamma p -> 3 (pi+ pi-) p it
> seems that my signal efficiency, using your code, is
> something around 10x more than what is obtained
> with the "stock" tracks provided by the reconstruction
> There are several problems/issues with this:
> * Tracks are something that should be provided to
> all users. As is, it is very hard for a user to get these
> recreated tracks, which seem to be, based on the
> efficiency gain, "real" tracks. We've tried to cook
> up a factory that creates 5 DReactions each of which
> has a single track that triggers your factory create the
> track hypotheses, that Ryan can then extract, but
> this is non-trival and we still don't understand the
> results (see question below).
> * This is slooow to do at analysis time. Your
> algorithm involves reswimming, which is really slow.
> We discussed some speed issues last week.
> I thought a lot of the slowness was in overhead
> in analysis classes, but I'm not sure. When Ryan
> started to use the kludge to get the recreated tracks
> his code slowed down by 5x - 10x. We shouldn't
> have to redo tracking at analysis... any redoing
> we are doing isn't nearly as good as what we
> could have done with the original hits.
> A question: how is the FOM for newly created
> track hypotheses determined? We see the pattern
> that some recreated tracks have an FOM of zero.
> These tracks are getting cut by Ryan's tracking
> FOM cut. However, they don't seem to be cut
> by my specified FOM cut. Does the analysis system
> ignore the FOM cut for tracks that it recreates
> from another hypothesis?
> It seems to me like we're trying to solve a tracking
> issue at the analysis stage and it is consuming a
> lot of analysis-time CPU resources and creating
> confusing for users.
> It seems we have a solution -- can we move it from
> the analysis libraries into the core tracking software?
> Matthew Shepherd, Associate Professor
> Department of Physics, Indiana University, Swain West 265
> 727 East Third Street, Bloomington, IN 47405
> Office Phone: +1 812 856 5808
More information about the Halld-offline