Hi Hiro, On Tue, 4 Sep 2001 20:44:52 -0500 (CDT) Hironori Ito <hito@students.phsx.ukans.edu> wrote concerning "Re: BRAT 2.0.35": > WHO TOLD YOU THAT YOU CAN DECIDE HOW WE CUT CENTRALITY!!! After a long discussion here at NBI, invovling all personel here at NBI, we came to the conclussion that the SDM centrality method was not advantegous over the SDE centrality. > Did Steve, Y.K, Ramiro and I (or somebody else working on mult > detector (I can not think anybody else) ) ever ask you to write the > centrality code??? No, but since you guys didn't deliever for the longest time, I originally made the SDM centrality modules, based on the independent work by Claus and I (see BAN 22). > If so, please let me know because I am not aware of it. If not, > please change it back to whatever it was. As I said in the mail, I have not changed the BrMultCentModule, which is the one you and Steve did. > After briefly reading your analysis note, I understand you can do > what Steve and I did 3-4 years ago. Well, fine, where was the code 3 or 4 years ago! Why didn't you share your experience back then? I have a hard time endorsing an argument I haven't seen in black and white. Saying simple, "we did that 3-4 years ago" is not good enough. > However, it is decided that the cut in multiplicity is easier > (normalization and background correction on a real data) and more > clear (presentation and discussion) than what you just have done. Well, that's all well and fine, except that the SDE centrality has the advantage of quick calibrations and quick analysis, independent of the multiplicity calibrations. You are welcome, in discussions, presentations, etc. to refer to BAN 34. All the graphs are avaliable for you to look at, play with, and so on. > Also, look at the other experiment at the RHIC. (STAR, PHOBOS and > even PHENIX though they also use ZDC) Well, STAR and PHENIX has a much more segmented inner tracking systems, and they can expect a mean occupancy of <1 in those detectors, thus really they have much less trouble defining multiplicity in the individual detectors elements than we have. I don't know, but my guess is that the same goes for PHOBOS. > If this still does not convince you, well it is too bad. I suggest you go back an read BAN 34 one more time and then come back, and we can have a (civil) discussion on all this. I'd really like to hear more comments on this. > In any case, just change it back. Otherwise, I will, and you will > really not be happy because I will change everything. As Claus wrote you, I did not change the method in BrMultCentModule. All I did in that module, was to remove a number of unused members, that is pointers BrSiCalibration, BrTileCalibration, BrSiParameters, and BrTileParameters objects, since they were not used and caused the module to do too much unneeded work. If you take a look at it, you'll be satisfied that nothing is changed in the algorithm. I can understand that this change may have confused you, and I should probably have explaind a bit more in details what I did. What I did, was to add to modules: BrMultCentCalModule: Calibration module for BrMultSdeCentModule. Maybe this should be renamed BrMultSdeCentModule, so as not to confuse the poor sods. No seriously, I think I'll change it to that. It makes more sense in any case. BTW, when will you and Steve deliever the calibration code for BrMultCentModule (and the rest of the TMA and SMA calibrations for that matter?) BrMultSdeCentModule ^^^ ||| Notice the "Sde" in the name! It does not overwrite your BrMultCentodule or even affect the operation of that module! This module implments the SDE centrality cuts, based on the calibrations done by BrMultCentCalModule, and as outlined in BAN 34. Also, I propegated that change to BrGlbPackage so that it uses * two instances of BrMultSdeCentModule * _as_well_as_ and instance of BrMultCentModule to make _3_ centrality estimates. Finally, I removed BrTileCentModule BrSiCentModule from the library libBratModuleCent, but the code is still present in BRAT (it just isn't compiled!). As you can see, I did not touch the thing you and Steve did. The centrality method used in the multiplicity paper is still avaliable and I haven't changed that at all. Frankly I am a bit surprised at your reaction, and I actually think it's a bit misplaced. As outlined above, and in my previous mail, the change only affects BrTileCentModule and BrSiCentModule, which was written by me (based on independent work by Claus and I) in the first place (see BAN 22). Again, these changes affect none of your code, only code that I did in the first place. If you had a problem with the BrTileCentModule and BrSiCentModule classes, you should have made yourself heard back then, but seeing that you didn't, I can only assume you didn't have a problem with those classes, and so you have little cause to scream now! So therefore, I have a heard time imagine what you revert. If you want to put back the unused members in BrMultCentModule, then fine by me, but be aware that it will unnessecariy worsen the performance of that code. If you want to bring back the BrTileCentModule and BrSiCentModule, then let me know, and I can do it quickly, but do not remove BrMultSdeCentModule. These classes are orthogonal and can easily work side by side (then we'd have 5 centrality methods in BRAT). Just be aware that I will not support BrTileCentModule and BrSiCentModule anymore, since they are really redundant. My guess is, that you misunderstood what I did. If that misunderstanding was due to inadequate description on my part, I beg your pardon. I hope this mail has put yours and other minds to rest on this issue. 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 : Wed Sep 05 2001 - 07:18:54 EDT