Hi Flemming et at, On Sat, 8 Dec 2001 17:40:32 -0500 "Flemming Videbaek" <videbaek@sgs1.hirg.bnl.gov> wrote concerning "Re: Minor change to BrMrsTrackingModule -- actul inNode/outNode concerns": > I was prompted by this note to the list, as well as recent reading > of code recently to come with the observation that we are NOT > dealing nicely with the eventnodes (inNode and outNode) in > increasingly many modules. > > It has now become common place in code to have statements like > > if datatable not in inNode > the look in outNode. > And I have even seen adding the outputtable to both inNode and > outNode. The later is extreemly bad practise. > It is obvious why this happens - some early module in the chain ... My I suggest we call it a pipeline, so that we do not confuse it with ROOT TChains. > ... write a rdo-objet to the outNode while some subsequent code then > wants to use this for analysis. This early lead to CH's invention > of the swithccontainer (that supplie outNode as both inpput and > outoput to a module but this does not solve all.) . I added the > AppendContainer that within the container add's the outNode to the > Innode, and then drops the pointer later. This, I guess, is needed if a module would like to use both an object from the original input node, such as a raw digit, as well as some object from the output node, such as an RDO (RDO-Object is a pleonasm). > Both these methods have the potential problem that the same > dataobjects are pointed through two different chains i.e. both in > inNode and outNode. That the same object is pointed to from both the inNode an outNode, in the case where inNode and outNode points to the same BrEventNode object, as in the case of BrSwitchContainer, does not, as far as I can tell, cause any problems for the modules, nor does it cause any problems for the later deallocation of the BrEventNode. If there indeed is a situation where that may be problematic, could you please outline that. Thanks. I'm not sure what you do exactly in the BrAppendContainer, but my guess is you in the start of the Event method add a pointer to the inNode that points to the outNode, and at the end of the method removes the pointer again. So any object added to the outNode section of the inNode, will be in the final outNode twice. This is clearly not what we want. However, the solution is simple _not_ to write to the inNode at all (except for modules that actually reads data from disk, like BrRawDataInput, BrEventIO, and similar). In summary, I think we got what we want in BrAppendContainer and BrSwitchModule. I don't see the potential problems, but I may very well have overlooked a some special situation that may cause problems. > I do not have a clear solution to this, but will state that making > every module add a peice of code to look for both in and out is > silly. One though namely to 'append out' by defaullt in the main > module also has its problem (I do not think this will work with > input/modules, unless we make input have the syntax Event(dummy, > event) ). I'm not sure I get your point here. Are you thinking about 3 BrEventNode pointer arguments to BrModule::Event? That seems like a really bad idea, since it will quickly obfuscate the code even more. > There might well be other cases where one could get into problems. > I think always using Append or Switch appropriate for a given > solution is a better scheme than the multiple coding. I agree. Incidently, I believe the far best solution, though not very practical, would be for us to use TFolder's. This class provides a hierarchic scratch area, where modules could register output. The real output would then be put in branches of a TTree. Hence, the TFolders would have pointers to the same objects that is put on branch. This would actually mean a speed increase, since you no longer constantly allocate and deallocate memory for RDOs, nodes, and similar. With the advent of TRef and TRefArray, this has actually become quite feasible, and still have complex structures where tracks points to constituent hits, and so on. Some more thought simnilar to this is given in "The Guide", section 3.3. Finally, modules could use the signal/slot mechanism to signal other objects that it is done with the event processing. While algorithms for track/hit/... finding and so on would not change ofcourse, alas, this will require a recoding of most of the basic classes in BRAT, and hence this will not happen in the foreseeable future (if at all). As for the problem at hand of the BrMrsTrackingModule: I think this problem could have been solved if someone using this module a lot, had provided an example configuration script in his/hers CVS area. Oh, and could we please have a search engine for out mailing list archives? Couldn't we get RCF to set up one for us? Pleeeeeaaaaassssseee. 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 : Mon Dec 10 2001 - 08:17:04 EST