[Halld-offline] Recreating tracks

Thu Aug 7 16:37:40 EDT 2014

Oh yeah, Simon, the DTrackTimeBased_factory_Combo factory probably already does some of what you would want ... you can look at DTrackTimeBased_factory_Combo::Create_TrackTimeBased() and see if any of that code is useable.  It's probably not everything you'd need though.  

 - Paul

On Aug 7, 2014, at 4:26 PM, Paul Mattione wrote:

> Thanks Simon.  You probably already know this, but one tricky problem is that sometimes the kalman filter will change the charge of one hypothesis but not the others.  Since the charge of these tracks is ambiguous, I'm currently treating them as if they could be either charge, which often invokes the re-swimming penalty.  In this case, could you have it create all hypotheses for each charge (pi+, K+, p, pi-, K-)?  Thanks.  
> 
> - Paul
> 
> On Aug 7, 2014, at 3:45 PM, Matthew Shepherd wrote:
> 
>> 
>> Simon,
>> 
>> Great - is this a problem you are working on?  It 
>> seems that real signal tracks are being properly
>> found as alternate particle species but not as
>> their actual true species.  I guess it means pattern
>> recognition is finding the track but somehow the
>> Kalman filter is failing?
>> 
>> If it was a small effect it wouldn't be a big deal, but
>> it seems to have a huge effect on efficiency, at least
>> in this one six-track topology we looked at.
>> 
>> If we can help with anything let us know, but I assume
>> that the events we have are not useful since they
>> are REST format without hits.
>> 
>> Matt
>> 
>> ---------------------------------------------------------------------
>> 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
>> 
>> On Aug 7, 2014, at 3:00 PM, Simon Taylor <staylor at jlab.org> wrote:
>> 
>>> Hi, Matt.
>>> 
>>> Regarding moving the resolution of the "missing track hypothesis" 
>>> problem to the tracking code itself, yes, this is doable.  Of course I 
>>> would prefer that the fit itself work for each track hypothesis, but in 
>>> the absence of this I will implement a fix to fill in the gaps using 
>>> existing track information.
>>> 
>>> Simon
>>> 
>>> On 08/07/2014 02: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
>>>> framework.
>>>> 
>>>> 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?
>>>> 
>>>> Matt
>>>> 
>>>> ---------------------------------------------------------------------
>>>> 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
>>>> 
>>>> _______________________________________________
>>>> Halld-offline mailing list
>>>> Halld-offline at jlab.org
>>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>>> 
>>> _______________________________________________
>>> Halld-offline mailing list
>>> Halld-offline at jlab.org
>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>> 
>> _______________________________________________
>> Halld-offline mailing list
>> Halld-offline at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/halld-offline
> 
> 
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline