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. > 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. > 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. > 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. > 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? > 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. * 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. * Eta I took out, but could put that in again, at least for the rings. * 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. 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? * You add some random number between -1/2 and 1/2 to the raw ADC - why? * You have, along with the vertex correction, also a "tilt" correction, which wasn't in the code before. Could you explain that? * 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. 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? > 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. > 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. 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 - 12:30:58 EST