Howdy brats. I updated BRAT after my not so successfull [:)] additions yesterday. New version bumbed 2.0.28 and tagged BRAT-2-0-28. On Fri, 17 Aug 2001, Christian Holm Christensen wrote: > Well, I don't mind the class BrSpectrometerTrackingPackage - tough > it's a bloody long name - so if you want to leave I have no real > problem with that. Hmm, maybe I made it a bit to easy to make new > modules/packages by introducing the Elisp function 'brat-class' :-) I renamed BrMrsTrackingPackage to BrMrsPackage and BrFfsTrackingPackage to BrFfsPackage. For now I also removed BrSpectrometerTrackingPackage. Anyone adding more functionality to the above mentioned packages should however have in mind that interface similar to both spectrometer arms could go into a base class like BrSpecPackage. > Uh! g2root does a full conversion of the GEANT3.21 [1] > volume/material/position/rotation common blocks (sigh) which is far > far too much for an event display. It all depends what you want to display. If you want to have the option of displaying different materials differently, e.g. with color coding, then this is not farfetched. > You should rather define the volumes in the detector > specific classes, using the service of BrGeometryDbManager. Also > note, that ROOT has already implemented the behaviour you're > addressing via globals gGeomtry [2]. My initial idea was actually to generate geometries/nodes using BrGeometryDbManager. But why do things twice as the ROOT geometry is easily with g2root. That was my reason for using g2root generated macros, as well as my point above regarding materials. > Hmm. All in all, I think all this belongs in a seperate package from > BRAT, since it's not likely that the code will be used outside of the > event display. The intention has never been to put TED in BRAT. Rather it should go into BROP as it will typically be used by shift operators. Some of the classes I made, however, I thought would be usefull in other contexts as well. Therefore they were put into BRAT. Anyhow, I've removed BrGeometryManager from BRAT. I'll see if I'll modify the implementation of detector geometries in TED or if I'll just leave it as it is, i.e. in TED with name BrVizGeomManager. > > > > BrTriggerManager Easy managing of trigger mask > > I guess you pass a given BrEvent through the regular BRAT analysis > modules to do tracking, and ya di da. Then, you might as well pass it > trough a BrTriggerFilter. > > Also, I see absolutly no reason why any analysis class needs access to > the trigger words, assuming you have filtered out the proper events > first. We (Flemming, Kris, and I at least) had a long discussion on > that some time ago, and the consequence of that was that > BrEventManager was depriciated for exactly these reasons. > > > > > BrEventInputManager Easy input of new events > > Well, it's really a cache isn't it? Also, you could easily combine > the services of BrEventList and BrEventInputManager into a module or > something, say BrCacheEventModule and use it with bratmain as: > > BrMainModule* mainModule = new ... > > BrIOModule* inputModule = new ... > mainModule->AddModule(inputModule); > > BrTriggerFilter* triggerFilter = new ... > mainModule->AddModule(triggerFilter); > > BrCacheEventModule* cacheModule = new ... > cacheModule->SetMaxEvents(10); > mainModule->AddModule(cacheModule); > I removed BrTriggerManager and BrEventInputManger from BRAT, at least while I try your suggestions. I also removed everything related to BrTriggerManager from BrEventList so that it can be used by others. The internal storage of events in BrEventList I'll test with different solutions as I move on. I guess that's all for now. 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 : Fri Aug 17 2001 - 13:14:47 EDT