> From: Christian Holm Christensen <cholm@hehi03.nbi.dk> > Reply-To: brahms-dev-l@bnl.gov > Date: Tue, 13 Feb 2001 18:29:47 +0100 > To: brahms-dev-l@bnl.gov, ssanders@UKANS.EDU > Subject: BRAT 1.14/00 (was Re: new BrRdoModuleMult and BrRdoMult modules) > > Hi BRATs, > > As you've probably seen from brahms-l, I've bumped the version of BRAT > to 1.14/00 and tagged the repository to BRAT-1-14-0. > > The new things are: > * BrTileRdoModule is more or less done (see my comments/questions to > Steve below) > * BrTileCentModule is done. It finds the centrality as described in > Claus and mine Brahms Analysis Note (BAN 22), and stores that > information in the output BrEventNode in a BrTileCent object. (name > is "CentMultTile"). > Current avaliable cuts are 5%, 10%, 15%, 20%, 30%, 50% and 100%. > * BrTileCent is done. Stores the lower and upper limit in centrality > e.g., .05 (5%) and .1 (10%). > * BrTileCentCalModule is done. it makes the calibration nessecary for > BrTileCentModule (see BAN 22). > * BrCentFilter is done. Filter to select events within a user defined > centrality region. > > Please note, that the method employed in BrTileCentModule is very much > different from J. H. Lee's Get_centrality.C script, and is applicable > in a much wider vertex region (+/- 40cm), and the calibration is > solely based on min-bias events. > > Please refer to BAN 22 for more information and considerations. > > On Mon, 12 Feb 2001 00:20:19 -0600 > Steve Sanders <ssanders@ukans.edu> wrote > concerning ": new BrRdoModuleMult and BrRdoMult modules": >> Hi, After working together with Hiro last week on resolving some >> final problems, I think we have a reasonably good module for >> obtaining the multiplicity and multiplicity based centrality for the >> si and tile detectors. > > Please refer to BAN 22 for a comparison of BrTileCentModule and > Get_centrality.C. Atlthough BrTileCentModule uses only the tiles, one > could make a similar module for the Silicon strip detectors. > The "best" final multiplicity should be obtained by averaging the two independent measurements. I would like to see a module that quotes this average and the corresponding centrality. >> Both sets of detectors are now giving consistent multiplicities and >> we should now be able to use the multiplicity based on the sum of >> the two measurements. The new modules correct for vertex locations >> between -20 and 20 cm. > > BrTileRdoModule, that is used by for BrTileCentModule, should in > principal work for any primary vertex Z position. However, Steve may > have some reasons why this is not so. > The vertex correction that Hiro and I use is based on Geant simulations. We do this because of concern that taking cuts using different experimental vertices might lead to a systematic error due to how "minimum" biased is defined experimentally. The current +/- 20 cm limit is only imposed because this is where Hiro had run geant simulations. >> Also, the modules use the latest "best" energy calibrations for both >> the Si and tiles. It should be noted that significant problems were >> found with the ealier energy calibrations of both sets of detectors. > > Could I ask you (Steve and Hiro) to look at BrTilePedCalModule > (pedestal calibration) and BrTileGapCalModule (ADC gap calibration)? > Is the lower gap value constant in time and over ADCs? In the old > code, is wasn't, but it seems that you now have the fixed value of > 4096. The lower gap position is not important so long as it is about the highest point for the low energy region. If a particle comes with a higher ADC value, the gap width is subtracted. > >> I was hoping to be able to develop a simple procedure for working >> with these modules but, alas, since I have not yet upgraded to the >> 2.25 version of root, I'm unable to compile the latest cvs version >> of brat... > > The problem of compiling BRAT with version 2.24.<xx> is realted to the > introduction of some methods in some of the base classes like > BrModuleContainer::SetOwner() and similar. However, I _strongly_ > suggest moving to at least ROOT 2.25/03 ASAP - that is currently the > "pro" version of ROOT, and ROOT 2.24/<xx> is very much inhibiting for > a great many things. > True... However when I tried to download the 2.25 version I ran into "library not found" problems. This is probably simple problem to fix, but it will take time and it is hard for me to estimate how long it might take to fix such problems. >> It still appears that the newest BB and ZDC vertices are shifted by >> a couple of cm for low multiplicity events. > > I'm not so sure that there's really a correlation between the > multiplicty of the tiles, and the Beam-Beam and ZDC Z-coordinate of > the primary vertex. Couldn't it be a feature of the geometry? I.e., > the fact that there are more tiles and strip detectors to the left > than to the right, giving larger accpetance? The offset that I'm referring to is found by tracking the energy of the single MIP peak as a function of distance of the vertex from the z-coordinate of EACH INDIVIDUAL detector. This should be symmetric. I find a systematic shift suggesting the vertex is located closer to the forward spectrometer than indicated by the BB module. Such a shift might also arise from a "tilt" of the detector element. I don't see an obvious reason why all of the array elements, both Si and Tile, should be tilted in the same manner, hence my concern about the vertex location. > >> I see two possibilities for getting these routines (or, more >> important, their functionality) into brat: >> >> 1.) Christian makes the functionality available within his new >> package. Here I only ask that the methods set up in the >> RdoMult module be preserved: > > What do you mean? Almost everything that was in there before is still > there. > Being unaware of your plan to revamp the mult directory, I was not keeping the cvs version closely in sync with my local development version. The old cvs version had NONE of the recent development efforts incorporated. > * I took out the raw ADC values from BrTileRdo, since those a present > in BrTileDig. > * I took out the average energy and multiplicity in the 8 rings and > over the full array, because the sum and number of hits in > rings/array are there and so the averages can be calculated. > * "Primary hits" are still there, but called multiplicity. > * The saturation thing wasn't in the old code, so that I didn't > include in the new. The tiles, in particular, have a saturation issue. > * Eta I took out, but could put that in again, at least for the > rings. This is useful when the vertex is not at the center of the array. > * You have centrality data in BrRdoTiles, but since that is now a > sperate object (BrTileCent), it should not be there any more. > * The "zavTiles" data member is new, and I haven't looked at it in > detail yet. > This is something I was exploring as a possible measure of the vertex shift, but I'm not sure how useful it will be yet. > The things you do in BrRdoModuleMult is more or less the same I do in > BrTileRdoModule, except for a few things. > * I do not consider saturated tiles, since that wasn't in the old > code, but I've seen that effect as well in the data. > * The way you correct for outliers - if I understand correctly from a > first read - is for a given ring to calculate the average and > variance, and reject any tile that is more than 3 variances > off. What I do (taken from J. H. Lee) is to disregard any tile that > contributes more than 10% to the total multiplicity of the > array. Could you comment on that? Earlier simulations of the array response within geant indicates this is a good way to correct for excessive energy events. I believe that disregarding a tile and then renormalizing is more likely to introduce a systematic error since tile location is important. > * You add some random number between -1/2 and 1/2 to the raw ADC - > why? Old habit of keeping "holes" from developing in spectra due to the discrete binning of ADC's > * You have, along with the vertex correction, also a "tilt" > correction, which wasn't in the code before. Could you explain that? See above. This is an important correction for individual detector elements. Also, you don't mention it, but the Si detectors have a VERY non-linear low-amplitude behavior because of the PTQ's. This is corrected in part by the pulser calibrations. > * Rather then using the names "tile<row>_<ring>", I have two maps, > that map the ADC index to a given row or ring. That is much easier > to implement in database software. Also, since I've split the Tile > and Si code, I don't need to test if I get a silicon strip of a > scinitilator tile. It should be easy to develop a conversion routine. I still find an advantage in maintaining a standard notation for the array elements that reflects the detectors location in the array. > > These are the differences I can see from one read-trough of your > code. Please let me know if you believe there are more. It's not easy > to tell, since there are a very few comments in your code and suffers > a bit from Fortrantitis. > > Could you be a little more specific as to what functionality you are > missing? Everyting associated with --Si and Tile energy calibration --Correction for excessive energy events --Quoted vertex dependent multiplicities and centralities for si, tile, and joint detectors using functions developed by Hiro In general, a way to get out the information that reflect the work that Hiro and I have put into calibrating the array response. > >> I have a large number of support and analysis programs that have >> been developed based on the BrRdoModuleMult and BrRdoMult classes. >> One advantage if Christian does the conversion is that, presumably, > > Gimme some credit will ya'! > > I'd much rather we'd have some iteration back an forth on this. I agree. > >> the parameters would then be properly incorporated into the brat >> database. >> >> 2.) Once the current crunch get over, I can work on the merging >> things in. However, I may have trouble finding time to work on >> this until after the spring term is completed. > > Don't we all? > >> Hiro has been working pretty much outside of the brat framework and >> expects to shortly have some modules that one can use interactively >> within root. > > Eh, how so? I strongly recommend you stay inside BRAT, that is the > modular concept, since that will make it much easier for everyone > concerned to use your stuff. True, if done cooperatively. > > 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 : Tue Feb 13 2001 - 14:43:56 EST