Hello, I second the "Watch it" regarding the BrGeometryManager. We have a BrGeometryDbManager (only an epsilon away from BrGeometryManager) which is in use and will be continue to be in use when we switch over to the MySQL access of the geometryDB (which by the way is in testing and seems to work) Kris Christian Holm Christensen wrote: > Hi Jens Ivar et al, > > On Jens Ivar Jordre <jens@fi.uib.no> > BRAT-2-0-27 wrote > concerning "Thu, 16 Aug 2001 17:17:15 -0100 (GMT+1)": > > Howdy brats. > > > > I have checked in a number of new classes and done some modifications to > > existing classes. The reason for most of this changes is TED, a TPC Event > > Display application I've made and which I'm about to make available. Look, > > Christian, no "BR....." name for this application. :) > > Need I remind you of CRASH? > > > New classes: > > BrMrsTrackingPackage Tracking in MRS > > BrFfsTrackingPackage Tracking in FFS > > Long names. BrMrsPackage and BrFfsPackage would be fine by me, since I > guess these packages also contains PID modules. > > > BrSpectrometerTrackingPackage Base class of the 2 clases above > > Is there any good reason for a base class here? Most packages are so > extremly simple, that having a base class is in most cases ludicrous. > > > BrEventInputManager Easy input of new events > > Why do you need this? > > > BrGeometryManager Manager of geometry nodes, for > > visualisation > > Watch it. We need to have a real geometry DB up an running soon, and > to not confuse things to much, I strongly recommend you change the > name of that class to something that people will not see as a > analysis/simulation geometry manager, say BrVizGeomManager. Why do > you need this manager in the frist place? I could rather imagine > having classes like in GEANT4, where you have something like: > > G4LogicalVolume: Knowns size, position, rotation and mother volume, > as well as how to draw it self in the mother volume. > G4PhysicalVolume: Derives from LogicalVolume. Has additional > information of material (defraction indicies, dE/dx, > and so on). > G4Detector: Contains LogicalVolume objects. Also knows how to > draw hits, tracks and so on in those volumes. > > In BRAT terms, we could have something like a class > > BrVizModule > > That essentially is like the G4Detector class, but in the BRAT-style: > > Init Draws detector in mother volume (CAVE, FFS, BFS, MRS) > Begin Redraws if needed > Event Draws hits, tracks, etc. > > The Viz is short for "visualisation" [en_BR] or "visualization" in > [en_US] > > > BrTriggerManager Easy managing of trigger mask > > You know that there's a BrTriggerFilter in BRAT already, don't you? > It has been evaluated by a great many people and found sound. I don't > see the need for an addtitional manager. Please elaborate on the > details of this. > > > BrEventList Event LIFO > > Why a LIFO? Why not a FIFO? > > > Modified classes: > > > > BrTpcTrackPackage > > Changed member fTrackModule to fTpcTrack module to make it consistent with > > BrTpcHitPackage. Also changed corresponding getter. > > Uh, I don't get this. > > > BrTpcClusterModule, BrTpcDeconvoluteClusterModule, BrTpcTrackModule > > Changed some variable names, i.e. histogram pointers, and also the title > > scheme. Now histograms are given titles according like "<Detector name>: > > <histogram description>", e.g. "TPM1: max ADC in clusters" > > BrTpcClusterModule::Event was also modified to be able to reset sequences > > in fSeqTable. The fClustNum member of BrTpcCluster is altered in > > BrTpcClusterModule::FindClusters and requires to be reset if an event is > > to be reanalyzed. Added Bool_t member fReset to BrTpcClusterModule and > > corresponding setter to allow the user to decide if he/she wants to reset > > the event at the end of BrTpcClusterModule::Event. The default is to not > > reset. > > Hmm. Are you sure this is not in conflict with some of Peter and > Djam's recent changes. > > These TClonesArrays need to be cleared, as you've seen. Otherwise we > get huge memory leaks. I recommend reading the chapter "Object > Ownership" in the ROOT Users Guide. > > > BrModule > > As many decendants of BrModule create subdirectories of gDirectory for > > their histograms, BrModule::Book now checks if the first newly created > > object is a TGDirectory. If it is it adds histograms from it to > > fHistograms. > > This is _not_ good. This means that we have to link the BRAT > applications, such as bratmain, against the ROOT GUI libraries. Very > bad, since it demands an extra chunk of RAM (~5MB I believe), and is > hence very inefficient; also the GUI has not been ported to all > platforms (yet). > > In fact, I was trying to get rid of all the dependencies on the > graphics libraries in BRAT - hence my request to make the TPC/DC > modules independent of the modules in modules/evdisp, which by the way > is straight forward. > > Please remove the references to TGDirectory ASAP. > > > BrFFSTrackingModule, BrMRSTrackingModule > > Changed their constructors to use the conventional "const Char_t* name, > > const Char_t* title" argument list instead of non-const. > > Great! > > > The new tag is BRAT-2-0-27 and version number was bumped to 2.0.27. > > Announcements on new BRAT releases should really go to brahms-soft-l. > > 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 : Thu Aug 16 2001 - 17:25:15 EDT