In regards to Steve's remark at the end. Not only is it ill advised. It was also
STRONGLY advised against.
Kris
Steve Sanders wrote:
> Christian Holm Christensen wrote:
>
> > Hi BRAT's
> >
> > Ok, I'm back (already I hear you say?) - sorry!
> >
> > I've bumped the version to 1.13.2 and tagged the CVS to BRAT-1-13-2.
> >
> > I've commited several changes to BRAT. Here's a short description:
> >
> > * Added the statig constant kInvalidValue to BrDataObject. This is a
> > huge float (1x10^200), so it's good as an invalid/bad value to
> > return in case of error or something like that. For example, all
> > the vertex algorithms could use this value if they can't find a
> > vertex, one can put it as a calibration constant that wasn't
> > fixable, and so on. The idea is to have it at an unreasonable value
> > (if you can think of any number in BRAHMS that would ever be that
> > high, then let me know, and I'll change the sign :-), and a symbolic
> > name for that unrteasonable value.
> > * Added the class BrVertexFilter for only accepting events within some
> > vertex cut. Histograms are produced.
> > * Revisted (almost) all of the multiplicity array code.
> >
> > I'd very much like to hear from J. H., Steve and Hiro (and anyone
> > else that have something to say ofcourse) what you think of this,
> > especially when it comes to calibrations and MIP corrections.
> >
> > In general, I renamed the classes to fit in with the scheme proposed
> > for BRAT 2:
> >
> > <Class name> ::= Br<Scope><Data Type><Type>
> >
> > <Scope> ::= Base
> > | Db
> > | Geant
> > | <Detector Type>
> >
> > <Detector Type> ::= Tof | Tpc | Dc | Chev | Rich | Bb | Tile | Si | ...
> >
> > <Data Type> ::= Track | Hit | Dig | Rdo | Cluster | Vertex | ...
> >
> > <Type> ::= { empty for data classes }
> > | Module
> > | Manager
> > | Package
> > | Filter
> > | Db { database data }
> >
> > * Split the class BrRdoModuleMult into two classes: BrTileRdoModule
> > and BrSiRdoModule, each working on the specific (sub) detector.
> > Also, both classes are all new. They are prepared for using the
> > database to obtain calibrations constants.
> > - BrTileRdoModule now uses - for the moment - the calibrations
> > from J. H. Lee, which are hardcoded into the code as static
> > variables. They should disapear very VERY soon. Also, it
> > corrects for the different paths lengths through the
> > scinitilator material dependent on the primary vertex position
> > along the Z axis, as pointed out by Jens Jorgen and Erik. The
> > class has been fairly well tested - see below on
> > brahms_app/cholm_app - and I'm fairly confident that it works.
> > - There are no calibration constants avaliable in the code or
> > database for the silicon strips, and the module hasn't been
> > tested.
> > * Split the class BrRdoMult into two classes: BrTileRdo and
> > BrSiRdo.
> > * Renamed BrDigTiles and BrDigSi to BrTileDig and BrSiDig. The old
> > classes are kept for backward compatibility, and BrTileRdoModule
> > and BrSiRdoModule knows how to use them.
> > * BrRawDataInput, BrRawDataOutput, and BrGeantInput now writes
> > BrTileDig and BrSiDig objects.
> > * Added calibration classes BrTileCalibration and BrSiCalibration
> > for use with the calibration database. They have not been tested
> > extensively, but should work as soon as we have an official
> > database server up and running.
> > * Added two skeleton calibration modules for the tiles:
> > BrTilePedCalModule and BrTileGapAdcModule, the former to find
> > pedestals, and the later to find the ADC gap. The pedestal module
> > should be ok, though it may need some polishing, but the later is
> > incomplete.
> > * Likewise, I added a skeleton calibration module for silicon
> > pedestals: BrSiPedCalModule.
> > * Added the class BrTileCent to store the upper and lower limit of
> > the centrality (in procent) of a given event.
> > * Added the module BrTileCentModule for making BrTileCent from
> > BrTileRdo and calibrations.
> > * Added the class BrTileCentCalModule for finding the cuts that
> > correspond to different centrality (in procent) for a given
> > primary vertex bin. As previously stated on this list, one cannot
> > lump all verticies into one histogram, and then find the cuts from
> > that, since the number of particles hitting the tiles vary greatly
> > over the primary vertex distribution. Therefore, this cuts must be
> > considered primary vertex dependent, and should be found as such.
> > We (Claus and I) hope to produce a note very soon.
> > * Updated BrMonitorMult, etc. to use new names.
> >
> > Though these changes are somewhat drastic, I feel reluctant to bumpt
> > to 1.14, since the changes are not all well tested yet.
> >
> > Also, I've made a directory in brahms_app called cholm_app, where I
> > put a number of programs, and intent to put some more.
> >
> > In the subdirectory "tiles" you'll find the program reduce.cxx, that
> > will produce Reduced Data Objects (Rdo) from raw data for the ZDC, BB,
> > and Tiles. It uses the RUNDB for accessing files, BrVertexFilter for
> > primary vertex cuts, and BrTriggerFilter for selecting triggers.
> >
> > I've also put the files "root-help.el" and "brat-help.el" into the
> > subdirectory "elisp".
> >
> > In brahm_app/cholm_app there's a README file with some more
> > information. Feel free to grap anything from that area.
> >
> > Ok, I know I set a short description, and it really is, even though it
> > may not seem like it (some 100 lines), but I've left out quite a lot -
> > sorry once again.
> >
> > 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
>
> Hi Christian,
> I will have to look at the code changes. My initial comment is that drastic
> changes done to code used by
> the detector sub components WITHOUT consulting with the people working on
> those subcomponents is
> ill-advised. Had I known you were about to do this, I would have committed my
> latest code versions that are
> being used in the analysis. Also, the on-line monitoring program also uses
> the current classes.
> Regards, Steve
This archive was generated by hypermail 2b29 : Tue Jan 30 2001 - 09:43:37 EST