On Thu, 16 Aug 2001, Christian Holm Christensen wrote: > > 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. At least so far I have not implemented PID, but I could do that. I'll change the names. > > 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. You may be right about this. My plan was to elaborate on an interface as similar as possible for MRS and FFS, so the interface was to go into BrSpectrometerTrackingPackage. I'll remove this one for now, but I don't guaranty I'll not introduce it later. :) > > 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] I'm using this class to process macro files generated from GEANT geometry using g2root. This class allows for easy access to different nodes (TNode) in the BRAHMS geometry. Since I use/plan to use it in several classes I found it easier to make it a manager than passing it as argument to the classes using it. I would also like it to be a singleton so that changes applied to it in one class shows up over all. I have found it usefull. The name, however, I'll do some modifications to it. > > 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. Ok, elaboration starts. (Do go and get a cup of coffee, i.e. an espresso as the elaboration is not long enough for a tall latte.) a) The same argument as for the geometry manager regarding singleton behaviour and use in other classes applies here too. Like BrGeometryDbManager you use it in different classes. You don't want to pass an instance of BrGeometryDbManager as arguement every time you create an instance of all the classes using it. Read the class description and try it out. b) Also I did't want to put any moduled into the BrEventInputManger/BrEventList where it does not belong. See below. > > BrEventInputManager Easy input of new events > > Why do you need this? > > > BrEventList Event LIFO > > Why a LIFO? Why not a FIFO? These two questions are related. Tpc3d allows the user to go through a list of events, both forwards and backwards. I didn't quite like the way this was done in tpc3d. Therefore I made BrEventList to store a certain number of events. I.e. the user specifies the maximum number of event to be stored, say 10. After pushing some number ( < 10 ) of events to the list, the user can wander back and forth within the list. Exceeding 10 events, the first events to be stored are the first ones to be stored............ Ok, I get the point. My fault and typo. It is of course a FIFO. :) I'll update. Some time one would typically like to use the event list, other times not. By using the event input manager, one can can have the same interface whether one chooses to use the list or not. I made it a manager to have it as a singleton. > > 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. Well, the variable names for TPC related modules of in BrTpcHitPackage all start with fTpc......., but BrTpcTrackModule had fTrackModule. Therefore I changed it to fTpcTrackModule. And I changed GetTrackModule to GetTpcTrackModule. Truly a cosmetic modification. > > 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. > >From looking at their changes and performing a number of tests I don't think there is any conflict. The only thing I do is infact to put BrTpcSequence::fClustNum back to -1, i.e. on sequences that are in the data table named "kTPCSequence <TPC name>" in the input event node. Just look at BrTpcClusterModule::ResetSequenceTable. Also the default behaviour is to not reset. > > 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........... Yes, new typo. Reading your mail the first time I could not understand why you brought GUI stuff into the discussion. Then I discovered it. Instead of TGDirectory I meant of course TDirectory. No GUI allowed here!! > Announcements on new BRAT releases should really go to brahms-soft-l. Comming up next time. Best wishes from Jens Ivar -- Jens Ivar Jřrdre e-mail: JensIvar.Jordre@fi.uib.no usually: Dep. of Phys., Allégt. 55, N-5007 BERGEN, NORWAY currently: Bldg 510D, P.O.Box 5000, Upton, NY 11973-5000, USA phone: +1-631-344-4223
This archive was generated by hypermail 2b30 : Thu Aug 16 2001 - 18:47:09 EDT