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. I am currently trying to bring up the new multiplicity and centrality calibrations for the 2001 run. This should be ready this weekend. 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. I have also had to modify it to use the cfd vertex from the ZDC class that Hiro produced--but has not committed. Also, the class does not look the the tpm1 track vertex but rather only checks the cluster vertex. 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 vertex method, leaving the old vertex in place. This is not ideal and having a BrZdcVertex object as you suggest would be MUCH nicer. ...steve 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'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. > >I therefore propose the following: >* Rename BrVertex to BrTpcVertex, and only include a data member stating >wether it comes from clusters or tracks. >* 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. > >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. > >All right - I expect there are still views on this on this list. Please >respond :-) > >[1] Hmmm... Perhaps it's time to stop this greeting-game? ;-) > >------------------------------------------------ >Bjorn H. Samset >PhD student in Heavy Ion physics >Mob: +47 92 05 19 98 Office: +47 22 85 64 65 >Adr: Schouterrassen 6 0573 Oslo Norway >
This archive was generated by hypermail 2b30 : Fri Nov 09 2001 - 19:33:34 EST