Hi Steve et al, On Thu, 12 Apr 2001 22:15:57 -0500 "Stephen J. Sanders" <ssanders@ukans.edu> wrote concerning ": BB vertex offset": > Hi, > one significant difference in the two calculations to the approx. 2 cm > difference found between the BB and TPM1 vertices. Bjorn, Yury, do you know why there's this difference? Steve, can we be absolutely sure that the BB vertex is "off" by 2 cm.? Or the ZDC vertex for that matter? Couldn't it be that the TPM1 vertex is off by 2 cm. (or 4 or 6 or ...)? In short, what is it that makes everyone so sure that the TPM1 vertex is the "best" and should always be right? I've previously suggested trying to extract a primary vertex position from all avaliable primary vertex meassuearments in a given event. How say you (all) on that? Bjorn, I've asked you this before but I can't remember getting a reply: What's the data members BrVertex::fVertex_sigma_<x|y> and BrVertex::fVariance<X|Y>? Sigma (or standard diviation or square root of the variance) is an intrinsic property of some probablity distribution, while "sample variance" (s^2) and "sample standard diviation" (s) is meassured quantaties. If, what you mean by these two members is that fVertex_sigma_<x|y> = sqrt(fVariance<X|Y>), then one of the sets is redundant (fVertex_sigma_<x|y>) and should not be present. A method (GetDiviationX() const { return TMath::Sqrt(fVarianceX); }) is what you need. > In the "old" analysis, I had explicitly worked this into the vertex > I (illegally) passed to the BrRdoModuleMult class. However, > putting such an artificial offset into the BrSiRdoMult and > BrTileRdoTile classes (both of which need the vertex) is likely to > cause consternation in the future. Oh yes. Another reason to use all avaliable vertex meassuarements to try to find some "common" vertex, stored in the event node. > Is there a reason why this offset is not incorporated in the vertex > returned by the BrRdoBB module? To me, it seems that such a "correction" should not be imposed on the meassured data, at least not at that stage. > For the moment, I have updated the mult modules to incorporate the > vertex offset. It should have a temporary character, maybe behind preprocessor guards. Uh. Steve (and others) please don't use fabs, sin, cos, tan, and other functions from cmath. Use TMath/BrMath instead. TMath is there to insure portabliblity (various compilers have different ideas of ANSI/ISO standard C - yes I know, stupid - ROOT doesn't). On Sun, 15 Apr 2001 21:43:11 -0500 "Stephen J. Sanders" <ssanders@ukans.edu> wrote concerning ": mult changes": > Hi, The BrSiRdoModule and BrTileRdoModule classes now report the same > (to better than .05%) multiplicities as > BrRdoModuleMult ---IF--- fOutlierMethod is not set, or is set to > kNoCorrection. Uh. That's a bit odd. To me it sounds like your stuff in BrRdoModuleMult to correct for exesive energy events did diddly squad - that can't be right. > The DEFAULT in BrTileRdoModule is now to set fOutlierMethod to > kNBICorrection. Uh. I really don't like that name. The correction that is conditional on fOutlierCorrection == kNBICorrection, is a correction to the number of possible tile hit to the actual number of tiles hit so that multiplicities across different events are comparable. Hence, the name should rather be something like kHitCorrection. Descriptive names, please. > This returns the previous mult for this class so as to maintain > consistentency with the current NBI centrality calculation. Yes, setting the outlier correction method to something different could screw up the centrality determination, as done in BrTileCentModule. Again, this is a very good reason to choose some other meassure for the "centrality" of an event, rather then the, much corrected, multiplicity. What do you think? 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 Apr 16 2001 - 08:02:35 EDT