Re: Track length and real vertex introduction?

From: Trine Tveter (trine@lynx.uio.no)
Date: Thu Sep 28 2000 - 16:47:53 EDT

  • Next message: hagel@comp.tamu.edu: "BrDCTrackingModule"

    Hi,
    
    On Thu, 28 Sep 2000, Ian Bearden wrote:
    
    > I guess
    > what we should do
    > is calculate the vertex very early in the processing and add it to the event node and
    > then in subsequent modules
    > read the vertex from the event node.
    
    Yes, that was our idea too (maybe also do consistency checks on BB, ZDC, TPM
    vertices at an early stage / collect them in one object - I seem to remember
    that this has been discussed before?)  
    
    > It may be possible
    > that BB/ZDC gives a
    > good enough vertex.  How many tracks must go through TPM1 before you can call it a
    > vertex?  Or, without
    > paraphrasing Dylan:  what is the probability that there is a track through the MRS from
    > an event for which
    > it is not possible to reconstruct a vertex using TPM1?  I guess this probability  is
    > rather small, unless the
    > problem is too many hits/tracks in TPM1.
    
    There are constraints to be fulfilled in both TPM1 vertex finders before
    vertexing is attempted:
    BrTPMTrackVertexModule: at least 2 tracks in TPM1 is required
    BrTPMClusterVertexModule: at least 50 hits in TPM1 (rather arbitrary number so far)
    
    We haven't tested the vertex finding efficiency for events with complete
    tracks through MRS, but the probability that a good vertex might be unavailable
    is not necessarily negligible.  To ensure (without inspecting each event visually) 
    that we have a reliable vertex, the estimated "error" must be required to be 
    small, and some otherwise pretty events, in particular at lower centrality, 
    might be "TPMvertexless" for instance because the z histogram peak is a little 
    too wide or has too few counts to trust it blindly.  Bjørn may have more
    details on this.
     
    Maybe one has to test empirically what vertex type is good enough for what
    purpose (e.g. PID in FS, MRS, separation of primaries / secondaries ... )
    and a series of decisions about emergency solutions / spectrometer tracking 
    abortion has to be implemented (?) 
      
    Another question (for the NBI guys.)  How is the improved clusterfinder 
    progressing (Christian's Tuesday message hinted that you have an upcoming 
    BrClusterFixer (BrBanana / ButterflyHunter?), or was that wishful thinking so 
    far?  What new functionality have you ended up adding to the BrTPCCluster?  
    
                                               Trine
    



    This archive was generated by hypermail 2b29 : Thu Sep 28 2000 - 16:53:42 EDT