Hi Steve, Bjorn, and other BRATs, On Fri, 09 Nov 2001 18:34:02 -0600 "Stephen J. Sanders" <ssanders@ku.edu> wrote concerning "Re: Vertex data objects - a nice little can of worms": > Hi Bjorn, > Although I am not opposed to making the vertex stuff more > organized, please be aware that the changes are likely to break a > fair amount of existing analysis code. Actually it won't - at least not stuff in BRAT - what ever you have lying around that isn't in BRAT I can not answer for. > I am currently trying to bring up the new multiplicity and > centrality calibrations for the 2001 run. This should be ready > this weekend. Yeha! > I bring this up because the mult analysis uses a vertex selection > switch embedded in BrMultUtil. This class already requires > modification because it uses the old BB rdo module. Erh, no it doesn't! I recently updated that module so that it uses the new BB vertex if avaliable, otherwise the old BB vertex. Don't you read the update reports on this list? > I have also had to modify it to use the cfd vertex from the ZDC > class that Hiro produced--but has not committed. Why not? > Also, the class does not look the the tpm1 track vertex but rather > only checks the cluster vertex. Well, as Bjorn pointed out, you can query a flag in the object to see if it's from the track or the cluster method - really simple. > My intention was to take the heat by committing Hiro's modified ZDC > class once I had the rest of the mult stuff working: He basically > has added a cfd Please explain this CDF vertex. > ... vertex method, leaving the old vertex in place. This is not > ideal and having a BrZdcVertex object as you suggest would be MUCH > nicer. Then why don't you guys work with Andrey (who's at BNL now) on making something, rather than both of you guys working in different and possibly redundant directions? > Bjorn H Samset wrote: > > >Hi dev'ils. [1] > > > >A little while back there was a discussion on this list about the > >future of the diverse vertex data objects. I can't remember that > >any definitive concusion was reached, so I thought I'd stick my > >neck out and reopen the subject. I think no real conclussion was reached. > > I've just rewritten BrTPMClusterVertexModule - that is I've > > cleaned up the code quite a lot - and I'd like some feedback on > > this before I commit it. > > > > I'm partial to making three vertex objects: > > BrTpcVertex > > BrBbVertex > > BrZdcVertex > > all deriving directly from BrDataObject. I don't think that the > > overlap between their members (a z position!) warrants a common > > BrVertex base class, and certainly not the current BrVertex which > > contains diverse strange tpc stuff. Well, there's at least one place where I can imagine it would be beneficial to have a common base class, even if it only contains the Z position + error - in BrVertexFilter, one could rely simply on that info being present (that is quarantied via the base class, no such quaranty exist in BrDataObject). Also, if we at some point decides to implement another method, say from the SMA or ALICE Si Trackers or somthing, having a base class will defently be very helpful. I totally agree that the current BrVertex class is not at all suitable as a base class - as you said it contains far too much TPC specific stuff. > > I therefore propose the following: > > * Rename BrVertex to BrTpcVertex, and only include a data member > > stating wether it comes from clusters or tracks. or BB or ZDC or something, though this is really redundant, since that information is best kept in the name of the object. There are 64(!) bytes of data in the name, and 64(!) bytes in the title, and they might as well be used for something sensible now that we are stuck with them - yes, I do not like that thing at all. > >* Make BrBbVertex derive from BrDataObject and add the relevant > > members/functions > >* Have Andrei make a BrZdcVertex, as he's currently working on all > > the other zdc stuff as well. He should really work Hiro on this, so that they can streamline the ZDC vertex methods. > > The alternative to this, as I see it, is to keep a class BrVertex > > but still remove the tpc-specific stuff from its current > > incarnation and making a BrTpcVertex anyway. This is of course > > just as easy to do, but I don't quite see the reasons for doing > > this. I think I gave a couple of reasons for that above. I recommend a BrVertex base class (deriving from BrDataObject) even though it may seem ridiculously simple - the benefiets far outweights the seemingly odd class - also, it's proper OO design! > >All right - I expect there are still views on this on this list. Please > >respond :-) Consider yourself commented! (Ok, bad english, but what the heck :-) > >[1] Hmmm... Perhaps it's time to stop this greeting-game? ;-) Why? It's fun! Yours, Christian Holm Christensen ------------------------------------------- Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 Denmark Office: (+45) 353 25 305 Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b30 : Sat Nov 10 2001 - 07:46:21 EST