Hi Bjorn, On Mon, 14 May 2001 05:29:30 -0400 (EDT) Bjorn H Samset <bjornhs@rcf.rhic.bnl.gov> wrote concerning ": Proposed changes to VTX directory": > > Heigh ho :-) > > Now that I suddenly have lots of time on my hands (yeah right) I > thought I'd get around to the long overdue cleanup of the TPC vertex > code. Here is what I intend to do - please comment on anything that > shold be done differently or additional changes. Good initiative! > I'll create BrTPCVertexModule, a common base module for TPC vertex > algorithms that handles filling of data objects etc. Er, is there methods that both modules have in common, and hence could benefiet from being in a base class, or is it purely cosmetical? In the first case - good idea, in the second case, hmm, well ok. > The two existing algorithms become > BrTPCClusterVertexModule > BrTPCTrackVertexModule Er, should be BrTpc... > and should function as before, except for the following changes: > 1) I'll get rid of the SetDetectorHits/Tracks - all data will be > taken from InputNode() What will you be excpecting in the input node - I hope you refer to the first argument to the Event method, and not to some method. I should think that BrTpcClusterVertexModule will look for clusters for the appropiate TPC, and BrTpcTrackVertexModule will look for tracks from the appropiate TPC. None of these classes should make tracks and/or cluster themselves. As far as I gather from the existing code, we need to have a few classes modifed to make that work. In particular, the cluster finding modules should store the clusters in the output node, that is the second argument to the Event method. Talk to Peter about that, he's got some plans. > 2) The parameters will be loaded via the module name instead of a > third creator parameter (i.e. Name will have to be "TPM1") Neat. > 3) My proposed cuts on well-determinedness will be included as default > (settable, of course), and VertexFound will only be 1 if these criteria > are met. I think I said this before, but just to repeate in case some one forgot, I would recommend having Set'ter methods with defualt arguments that are what you intent to be the default parameter value, and then send that Set'ter message without arguments in the CTOR: class BrFoo : public BrModule { private: Int_t fParameter; public: BrFoo(const char* name, const char* title) : BrModule(name, title) { SetParameter(); } void SetParameter(Int_t param=42) { fParameter = param; } ... }; in that way, the default value is plain as day, appears only once and is easily changed. > I'll also add proper statistics histograms, which have been sadly lacking, > and do some cleanup of the algorithms themselves. I hope to fix the > y-problem with the ClusterVertex. BrVertex will be cleaned up a bit > (should it be called BrVertex, or was the old name BrVertexData better?) BrVertex is the right thing. > BrVertexModule will be updated to reflect these changes, but I'd like some > input on the future of this class. I intended it to be a common vertex > class that looks for data from BB, ZDC, TPM1 and in the future TMS/SMA, > and creates a BrVertex for each (either by picking an existing one or by > using a VertexModule or RdoModule) and then possibly setting a flag on > vertex consistency, (calculating a mean vertex?) etc. Is this a useful > module, or will vertexing in any case be done "here and there" so that a > common collector only adds confusion? I think, that we'd be better of to seperate out the vertex finding from the BrBbRdoModule, BrZdcRdoModule, etc., since that gives the user more options to customize her analysis jobs. It'd be much easier to insert a user defined ZDC vertex module, insert filters, and so on. Some has expressed that the seperation of Rdo and Vertex finding may be a bit to much, but I really like the idea of small modules that does only one thing, since, as outlined above, it gives the user much more control. In any case, I think the BrVertex members of some Rdo classes should be taken out and put in the event node by it self. If I'm looking for a vertex, I don't nessecarily also want to read multiplicites, energies, times, and so on. In case you start storing more data on TTree's this seperation will be extremly time/memory-saving since you'll only read the BrVertex data, and not the full Rdo data. Loads of time saved there. So to summarise: So far as BrVertexModule provides some algorithms that are usefull for all vertex algorithms I think it's a bloody good idea. If it's a matter of cosmetics, alright, I can live with that. If none of that, I really would rather see it go. > Well - I expect there are some opinions on this ;-) The changes will be > ready in a day or to, so do shout. Consider this an encouraging cry: Vikingerne Kommer!!!! > Ping :-) Pong. Oh, and congrats on your master thesis! - hope to get there soon myself. Yours, Christian ----------------------------------------------------------- Holm Christensen Phone: (+45) 35 35 96 91 Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 DK-2200 Copenhagen N Web: www.nbi.dk/~cholm Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Mon May 14 2001 - 09:16:56 EDT