Hi all, On Mon, 5 Nov 2001 22:14:07 -0500 "Flemming Videbaek" <videbaek@sgs1.hirg.bnl.gov> wrote concerning "Re: BRAT-2-1-23": > This discussion is partly academic, but it is worthwhile to note > that NO annouchement had been made that the classes like > BrMRSTracking , BrFFSTracking would disappear. A re-write of the > tracking objects was annouched, and likely to the good. In the > future it is imperative to give all people a grace period before > removing classes, e.g as was done with tpc, and mult classes in the > past while keeping the older classes. Being 'the original sinner' and admitting as much - I'd like to second Flemmings policy statement, that due warning is needed. Now, having said that, we need also realise, that we have an abundance of classes in BRAT that are not used, of no pratical use, or simple needs complete rewrite - the later is fortunally mostly modules; fortunatly since that does not effect data already written to disk. I think that much of the confussion we've seen in the past as to what does what, is partly due to these superflous classes, and we should really help our self by doing periodic clean-ups (garbage collection :-). To that end, I'd like to call your attention to the README and TODO files, as well as the recent questions possed by Peter on some of the tracking code. Please, if you know of unused classes, or believe some classes to be unused and obsolete/redundant, write a Intent To Remove (ITR) to brahms-soft-l, and if noone replies within a week or so, go a head and remove the stuff. I'd like to call the attention to a number of particular classes that really need some thought: BrDriverDC ---------- BrDetectorParamsDC uses this class - this is bad, since BrDriverDC lives in the modules part of BRAT while BrDetectorParamsDC lives in the data part. We would very much like to keep the data part independent of the modules part, as the modules part changes often and the data part doesn't (at least shouldn't). This can solved in 2 ways: 1) Make BrDetectorParamsDC independent of BrDriverDC. This is the one I prefer. 2) Move BrDriverDC into the data part of BRAT. This I don't like, since BrDriverDC is not a persistent class and holds no data, but basically provides some services for 2-3 modules. The point raised in 2) actually points to a rethink of BrDriverDC. I think the proper way to implement this class, is as an 'Attributes' class, much like TAttLine, TAttFill, etc. in ROOT or BrMultUtil in BRAT. Hence, modules that need the services of BrDriverDC (properly named something like BrDcUtil - it's not a hardware driver in the most strict sense of the word), can have multiple inheritance like: class BrDcTrackModule : public BrModule, public BrDcUtil Could the DC people please these issues a tought-over? Thanks. BrPid ----- This class uses TParticlePDG which gives some odd dependencies on ROOT libraries to the libBratDataPid library, namely the libraries EG Physics Graf3d Matrix Graf Hist While the two first libraries are OK, the rest is bad, since that has to do with graphics, ladida, which really should be avoided in the data libraries. Hence, I'd recommend (contrary to my own prior recommendation) that the dependency on TParticlePDG is removed. TDatabasePDG has all the manager functionality that insures that not too much memory is wasted in case of multiple instances of TParticlePDG. Claus and Djam, could you please look into that? Thanks. BrDigitizeTPC BrDigitizeDC BrDCTrackingModule ------------------ These classes uses the classes in modules/evdisp. This bad, since the modules/evdisp classes does not really belong in BRAT, but rather in some dedicated event displayer package, sort of what Jens Ivar have developed for the TPCs and DCs. Further, the classes in modules/evdisp forces some really odd dependencies on ROOT libraries, similar to the ones stated above for BrPid. This means, that bratmain will need to be linked against X11 libraries needlessly, there by creating and overhead and loss of efficency. Finally, I don't believe the classes in modules/evdisp are really used at all, since much better event display functionallity exists outside of BRAT. I'd like to urge the TPC and DC fellas to look into this ASAP. Thanks. These are the worst cases in BRAT at the moment. Other odd dependencies exist, please refer to the BRAT README and TODO files for more details. Yours, Christian Holm Christensen ------------------------------------------- Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 Denmark Office: (+45) 353 25 305 Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b30 : Tue Nov 06 2001 - 07:00:08 EST