Re: updated BrZdcRdoModule

From: Bjorn H Samset (bjornhs@rcf2.rhic.bnl.gov)
Date: Mon Aug 06 2001 - 03:51:45 EDT

  • Next message: Eun-Joo Kim: "Peter's Request"

    On Sat, 4 Aug 2001, Christian Holm Christensen wrote:
    
    > Hi Andrey,
    >
    > On Fri, 3 Aug 2001 19:28:35 -0400 (EDT)
    > Andrey Makeev <makeev_a@rcf2.rhic.bnl.gov> wrote
    > concerning ": updated BrZdcRdoModule":
    
      <snipped digi-talk>
    
    > >         // z-vertex
    > >
    > >         GetZ ();
    >
    > >From the perspective of modularity, I believe it be a good thing to
    > seperate out the vertex determination from the RDO module and make a
    > new module called BrZdcVertexModule, using the BrZdcRdo data to make
    > an BrVertex module.
    >
    > I believe a similar approach is on the way for the Beam-Beam
    > counters.
    
    Agreed agreed, but haven't we been through this before and found that
    Flemming disagreed on making a BrVertex for each detector? If that
    recollection is wrong I strongly second this motion.
    
    > While on the subject, I'd really like to see BrVertexModule turned
    > into a proper package (it's not a module - it's a package).  Who ever
    > did that module in the first place, could you look into it please?
    
    I made the module - just wrote up a quick shell and then didn't edit it
    because I knew things would change in BRAT2 anyway... I'd be happy to
    write the package, but if you think you need it as of yesterday I may not
    be able to deliver. I'm tied up elsewhere in a fulltime job until the end
    of october, so I can only do BRAT stuff in the evenings... So - if a week
    or two is time enough I can do it, but if not I suggest the responsibility
    move on for a while. Your call, everyone: <insert answer here>
    
    > If the vertex determination is seperated out of the ZDC and BB RDO
    > codes, it'll be extremly easy to make a BrVertexPackage: It should
    > only contain a BrZdcVertexModule, BrBbVertexModule,
    > BrTpm1ClusterVertexModule, BrTpm1TrackVertexModule, and perhaps a
    > BrSumVertexModule, the last being a small module that will try to make
    > the best possible vertex from all of the other methods.
    
    Aye, lovely. The wonders of modularity :-) We still need some discussion,
    though, on just how the summed/avereaged vertex should be calculated and
    in fact wether it is really usefull. For one, we should not use both track
    and cluster vertices as they are not independent. The simplest thing then
    is of course a weighted mean of BB/ZDC/TPM1 where avaliable, but I'm
    wondering if this will really make the determination better. At least last
    year, we found it way preferable to deal with the quirks of one
    determination only even if it was not the best one in some cases. Or maybe
    use the "best" avaliable vertex in each case and not mix them. It gets a
    lot harder to estimate systemaitc problems if we use a summed vertex...
    
    Also, for the SMA/TMA people: Can you also produce a BrMAVertexModule? It
    would be an invaluable tool both for testing and physics, and could give
    us our only (rough) x-determination (?).
    
    Ping :-)
    
    ------------------------------------------------
    Bjorn H. Samset
    In administrative exile, but with access to free coffee :-)
    



    This archive was generated by hypermail 2b30 : Mon Aug 06 2001 - 03:53:06 EDT