Hi Christian, Thanks for the detailed answer. I have gotten things working with the SwitchModule--This is a very nice system and I would like to focus my own work around this framework. As more code gets developed along these lines, however, the SwitchModule (or its functional equivalent) should be made part of the standard brat structure. FYI, when I tried a make in your jobs directory, the process stopped with a const error working on GlbPackage. This came after the SwitchModule library was already created, however, so wasn't much of a problem. ...steve Christian Holm Christensen wrote: > 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 - 11:48:42 EDT