About the model dependency. It is not model dependent!!!!!!!!!!!! Look at the dE/dx plot for pion since it is the most dominat paritcle. And, look at the momentum (or kinetic energy) distribution of pion, and count how many pions are not mip. (a lot of them particulary at 90 degree) If you think dE/dx is flat for all momentum, you are way wrong!!!. Our code is not model dependent, but particle momentum dependent (by small amount) Hiro On Fri, 4 May 2001, Christian Holm Christensen wrote: > Hi Steve et al, > > (again, this mail looks rather long, but most of it is figures, so do > read on. To me, I guess, brevity is something they do else where.) > > On Thu, 03 May 2001 21:06:01 -0500 > "Stephen J. Sanders" <ssanders@ukans.edu> wrote > concerning ": Re: BRAT update and Re: centrality and question": > > Hi Christian, Thanks for the very clear example. I have gotten my > > script working, but your example is much cleaner. My only concern > > is your comment that the script will not currently work because of > > problems with some of the modules. > > Yes. However, if you choose to ignore these modules, or eloborate on > the wrapper class given at the end, then I will work. So in > principal, you could use that script. > > > We need to have a way for people working on the various charged > > particle multiplicity analyses needed for the paper to get hold of > > the common centrality values in the very near term. > > Yes. In fact, I'll go as far as to say that we need that for _any_ > kind of analysis. That's why I'd really like for you (all of you) to > comment on the wether you think it's a good idea to use the energy > deposited rather than the (model-dependent?) multiplicity. > > > > I understand Hiro and Yuri have already reworked the Si, Tile and > > BB analyses with some very encouraging results. However, we still > > need the reworked tpc results using the common centralities. > > What Claus did, uses BrTileCentModule i.e., not that different from > the thing in BrMultCentModule. > > > Hopefully, the non-conforming classes will be corrected shortly. > > Yes, let's hope so. It's really very simple. Output _must_ go to the > BrEventNode passed as second argument to the Event method, and input > _must_ be looked for in the BrEventNode passed as first argument. > This is crucial for the modules to incorporate into the framework. > Please note, that some times you really don't care about some > analysis, say tracks, but only want things that leasd up to that, say > clusters; therefore it should be possible in a standard way, to get > only the subset you need. Also, only trivial Getter and Setter > methods for algorithm parameters can be public, the rest are to be > incapsulated as private or protected. > > On Thu, 03 May 2001 21:28:29 -0500 > "Stephen J. Sanders" <ssanders@ukans.edu> wrote > concerning ": FindVertex": > > Christian, At the moment the same vertex calculation is done in > > three classes: BrTileRdoModule, BrSiRdoModule, and > > BrMultCentModule. > > Strictly speaking, these were not _calculations_ but rather > _retrivials_, at least until you decided to put in a BB offset "fix". > > > Is there any reason why we can't have one vertex module that > > attaches the vertex to the event node? > > That was what I suggested some time ago: to have a one vertex > calculated on the basis of the avaliable verticies in the event. It's > probably be something like a weighted average or similar. However, no > one spoke up about this, and I'm not too familiar with that part of > the code, that I'd feel comfortable doing such a module myself. > > > I can easily imagine wanting to modify the specifics of the vertex > > selection, ... > > Selecting verticies should not be done in modules other than a > designated module i.e., BrVertexFilter, since that will effectively > hide cuts in the data. Therefore, the analysist must herself define > the cuts by instantising a BrVertexFilter, set the proper cut values. > > > ... and I worry about the potential of developing different vertex > > locations in the different modules. > > Well, as long as FindVertex only looks for data in the input > BrEventNode, and doesn't apply "fixes", then there's no problem; it's > the same thing as looking for digits in the input. > > However, as soon as you start to do selections and calculations in > such a method, you're in trouble, and the analysist will be in even > more trouble, 'cause there'll be descrepancies between the data used > and the output data , along with hidden cuts and so on. > > This is exactly why I suggested a "common" vertex module (see above), > and I imagine something similar should be made for the centrality. > > > If we develop a new module, should it be called BrMultVertexModule with > > corresponding BrMultVertex? > > If you develop a module that uses all avaliable verticies to get a > "common" vertex, I suggest you'd call it BrCommonVertexModule, and it > should derive from BrVertexModule and write BrVertex object to the > BrEventNode passed for output. > > What I also would like to suggest, now that we are talking about > primary vertex determination, is to split that part away from > BrZdcRdoModule and BrBbRdoModule proper, and call the new modules > BrZdcVertexModule and BrBbVertexModule, and both should create a > BrVertex object in the output event. Ofcourse this will reguire that > BrVertex has some way of telling the user wich detector/method was > used. > > Something similiar could also be defined for the centrality data and > modules. > > Here's what a class diagram could look like: > > Legend: <- Inherits-from relation > o-[] Has-a relation > > Modules: > > BrModule <-+- BrVertexModule <-+- BrBbVertexModule > | | > | +- BrZdcVertexModule > | | > | +- BrTpcVertexModule <-+- BrTpcClsVertexModule > | | | > | | +- BrTpcTrkVertexModule > | | > | +- BrCommonVertexModule > | > +- BrCentModule <---+- BrTileCentModule > | > +- BrSiCentModule > | > +- BrCommonCentModule > > Data: > > BrDataObject <-+- BrVertex > | > +- BrCent > > > Packages: > > BrModuleContainer <-+- BrVertexPackage o-+-[] BrBbVertexModule > | | > | +-[] BrZdcVertexModule > | | > | +-[] BrTpcVertexModule > | | > | +-[] BrCommonVertexModule > | > +- BrCentPackage o-+-[] BrTileCentModule > | > +-[] BrSiCentModule > | > +-[] BrCommonCentModule > > I hope this illustrates what I mean. Incidently, this kind of class > diagrams (though usually done with clouds) are called Booch diagrams. > > The flow would then be: > > > ---------- > Raw Data -----------------+ > ---------- | > | | > V | > ( BB, ZDC, TPC Rdo Modules ) | > | | > V | > ----------------------- | > +------- BB, ZDC, TPC Rdo Data | > | ----------------------- | > | | | > | V | > | ( BB, ZDC, TPC vertex modules ) | > | | | > | V | > | --------------- | > | BrVertex data | > | --------------- | > | | | > | V | > | ( BrCommonVertexModule ) | > | | | > | V | > | --------------- V > | BrVertex data --> ( Tile, Si Rdo Modules ) > | --------------- | > | | V > | V -------------------- > +--> ( Tile, Si, BB+ZDC cent modules ) <-- Tile, Si, Rdo Data > | -------------------- > V > ----------- > Cent data > ----------- > | > V > ( BrCommonCentModule ) > | > V > ----------- > Cent data > ----------- > > 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 : Fri May 04 2001 - 13:36:19 EDT