Vertexing - forwarded from Bjorn

From: Trine Tveter (trine@lynx.uio.no)
Date: Tue Jun 06 2000 - 09:10:34 EDT

  • Next message: Flemming Videbaek: "Re: Brat Problems"

    ----- Begin Included Message -----
    
    >From bjornhs@fys.uio.no Tue Jun  6 11:14 MET 2000
    Date: Tue, 6 Jun 2000 11:15:19 +0200 (CEST)
    From: Bj|rn Hallvard Samset <b.h.samset@fys.uio.no>
    X-Sender: bjornhs@brahms.uio.no
    To: brahms-dev-l@bnl.gov
    cc: jhlee@sgs1.hirg.bnl.gov, bearden@hehi03.nbi.dk, hagel@comp.tamu.edu,
            Trine Spedstad Tveter <t.s.tveter@fys.uio.no>
    Subject: Vertexing
    MIME-Version: 1.0
    Content-Transfer-Encoding: QUOTED-PRINTABLE
    
    <If this mail doesn't show up on brahms-dev-l, could someone please
    forward it there? Sorry about double-mailing some of you - I am trying to 
    figure out this mailing-problem>
    
    Hello all :-) I'll try to give some comments on the issues raised in the
    last few e-mails on this subject.
    
    First of all, I have never suggested that BrHCVertex should be our only
    primary vertex-finder. The reason that I have concentrated on this method,
    as I said in my last mail, is that tracking has long been far from optimal
    and thus given JH's BrVertex too little to work with. As JH says, BrVertex
    is a fast method that gives the vertex quite precisely in y and z, and
    better the closer mid-rap is to 90 deg - but it needs enough tracks. Now
    that tracking has evolved quite a bit I think it will do even better than
    it has done before, and I would like to work a bit further with it if JH
    thinks this is ok. (Please note: The current CVS-version of BrVertex
    includes code for a "turnable plane of determination" that I made to try
    and get the x-coord too - I checked in the wrong version and will fix this
    shortly)
    
    As for BrHCVertex, this far it has given better results than BrVertex in z
    for all simulations I have tried but as I said this may well have changed
    with the improved tracking. I will look into this thorougly, and give a
    presentation to you (either on a web-page or when I come to BNL at the end
    of the month). Two points: 
    1) BrHCVertex will probably be able to determine y and possibly x too - I
    just haven't had time to test my ideas due to exams and illness.
    2) Now that I am familiar with the bugs in the ROOT peak-finder (see
    below) I do have an uncertainty-estimate in BrHCVertex. It currently comes
    in the form of the sigma of the gaussian that finds z, but this will be
    worked on further.
    
    What I would actually like to do, is to make a module that uses both these
    methods plus ZDC-data etc. to double-check vertex-locations, plus do
    secondary tracking to possibly find secondary vertices. Plus, the methods
    are in fact somewhat complementary as BrVertex is at its best with mid-rap
    close to 90 deg. and vertex close to z=0, while BrHCVertex is slower but
    deals better with other angles and vertex-locations.
    
    Naming: I propose the following naming-changes:
    BrVertexData becomes BrVertex (I agree with Chris...)
    BrVertex becomes BrTPMTrackVertexModule
    BrHCVertex becomes BrTPMClusterVertexModule
    
    This leaves room for a common BrTPMVertexModule which could either just
    be a supermodule that uses the two others, or a base class from which they
    derive. (I'm not sure that this is a good idea in this case, since they
    have very little in common structurally, but it would follow our Brat
    conventions)
    
    A note on problems with ROOT:
    I have made extensive use of the ROOT fit-function (TH1->Fit()) to fit a
    gaussian to my data. When I do this in a macro in interactive ROOT and run
    the program more than one time (e.g. not restarting ROOT) the fitter does
    strange things. Eiher it sometimes puts a linear, diagonal background on
    top of my fitted data, or it fits the peak nicely but then offsets the
    result by exactly 3 cm. (3 units on the axis) It appears that something,
    somewhere is overwriting some memory (uncontrolled pointers, most likely),
    but after scanning my code quite a number of times I cannot find an error
    there. Has anyone else had these problems with the
    fitting-functions? Anyway, the problems seem to disappear once things are
    compiled so this is only a problem during coding and testing...
    
    Well - that was a long mail. To summarize: I wish to keep working with
    both TPM1-vertexfinders, and give you a presentation when I come to BNL. I
    will also, if you approve, make the above naming-changes etc. shortly - I
    just have to finish my exam on thursday first :-) I am sorry that the
    vertex-finder has not progressed quicker, but as I said this has been due
    to many courses and illness...
    
    Cheers
    ------------------------------------------------
    Bjørn H. Samset                   
    Hovedfagsstudent, tungionefysikk     
    Mob: 92 05 19 98  Lesesal: 22 85 77 62
    Adr: Kri 2A709 Sognsveien 218 0864 Oslo
    
    
    
    
    
    
    ----- End Included Message -----
    



    This archive was generated by hypermail 2b29 : Tue Jun 06 2000 - 09:15:28 EDT