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 : Mon Jan 29 2001 - 19:15:16 EST