Hi Steve et al, On Mon, 04 Jun 2001 17:11:44 -0500 "Stephen J. Sanders" <ssanders@ku.edu> wrote concerning ": module container question": > Hi Christian (or anyone else who might have an answer...), > I am trying to follow your CentMacro.C macro as a template for > doing the centrality analysis. See also RcfConfig.C, NbiConfig.C (specific to our setup though), GlbPackage and so on in brahms_app/cholm_app/jobs/global > After a few minor changes (defining input and output files) I have > been able to succesfully run the macro in an interactive root > session. Good. I wasn't 100% sure it'd work, since I didn't try it myself. > This encouraged me to try adding the BrMultCentModule to the mix. Glad you like BrMainModule. > The main changes were: > > ...in the calibration section added > > BrMultCentTmpCalibration * centCalib = > BrMultCentTmpCalibration::Instance(); > > ...after the SMA module code added > > BrMultCentModule * centModule = > new BrMultCentModule("MultCent","Cent Module"); > mainModule->AddModule(centModule); > > My question/problem is that I seem to be missing something. When I > try to run this as a macro file, the BrMultCentModule complains that > it can't find the tile rdo file. Since the BrTileRdoModule is loaded > into the container before BrMultCentModule, I thought it would > already have added the associated rdo to the chain. Any suggestions > as to what I'm doing wrong? You're not doing anything wrong per se. The problem is that of the "swiching nodes". See what happens is that we have to event nodes parallely passed down to all modules, like inNode outNode | | V V +-----------------------+ | BrTileRdoModule | +-----------------------+ | | V V inNode outNode | (with BrMultRdo) | | V V +-----------------------+ | BrMultCentModule | ====> Chokes. Can't find BrMultRdo in +-----------------------+ inNode | | inNode outNode V V +-----------------------+ | Ohter Modules | +-----------------------+ So what'd you'd like is for BrMultCentModule to recive the outNode of BrTileRdoModule as _both_ it's input and it's output. That is: inNode outNode | | V V +-----------------------+ | BrTileRdoModule | +-----------------------+ | V outNode (with BrMultRdo) / | V V +-----------------------+ | BrMultCentModule | +-----------------------+ | | inNode outNode V V +-----------------------+ | Ohter Modules | ====> Chokes. Can't find it's input +-----------------------+ However, subsequent modules may want the original inNode (with Digits in), so just duplicating the outNode as inNode won't work (and will cause a memory leak + SIGSEGV). Therefor I introduced a SwitchModule (see brahms_app/cholm_app/jobs/general), that will redirect the previous outNode as in node for the contained module: inNode outNode | | V V +-----------------------+ | BrTileRdoModule | +-----------------------+ | | | V | outNode | (with BrMultRdo) | | V V +-----------------------+ | SwitchModule | +-----------------------+ | | inNode outNode | | \ | V V | +-----------------------+ | | BrMultCentModule | | +-----------------------+ | \ / | \ / V V +-----------------------+ | Ohter Modules | +-----------------------+ This quaranties that you'll only duplicate the outNode for one module (you can of course do that as many times as you like), so that subsequent modules get the right inNode. To use that module, instead of the addition of BrMultCentModule you did above, do BrMultCentModule * multcentModule = new BrMultCentModule("MultCent","Full MULT Cent Module"); gSystem->Load("SwitchModule.so"); SwitchModule* multcentSwitcher = new SwitchModule("multcentSwitcher", "Switcher for MultCent"); multcentSwitcher->SetModule(multcentModule); mainModule->AddModule(multcentSwitcher); Please note that I _do_not_ add the BrMultCentModule object to the main module. See also GlbPackage referenced above for how I do all that in a package (I add the Br[Tile|Si]CentModule via switchers too). SwitchModule isn't a part of BRAT (yet?) - since I want to know from Flemming and Kris wether they think it's a good idea or not (and maybe a better name too). I hope you've found this way of making analysis jobs much more simple than your MultReplay class, which suffers terribly from Fortrantitis: that is one program does it all. The idea of BRAT's modules (and in many ways of C++ itself) is that you make simple components that only does a very specific job - nothing more nothing less. You then build up your application using these components. Using ROOT and BRAT, we have the additional advantage, that we do not even have to know what modules we have avaliable when we build the system - we can always plug them into the pipeline (assuming they compley to the BrModule interface) as we see fit. I hope this will encourage you to also flesh out the modules Br[Si|Tile]PedCalModule and BrTileGapCalModule as it seems that you have the methodology down in MultReplay, but in a form that's not very consistent with BRAT I'm afraid. It would be nice if everyone could do the calibrations easily (see what Djamel did for the TOFs). I hope this helps you. Yours, Christian ----------------------------------------------------------- Holm Christensen Phone: (+45) 35 35 96 91 Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 DK-2200 Copenhagen N Web: www.nbi.dk/~cholm Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Tue Jun 05 2001 - 05:26:38 EDT