Hi Micheal, On Thu, 24 May 2001 10:11:52 -0500 Michael Murray <murray@CyclotronMail.tamu.edu> wrote concerning ": Re: Database access from rdo module": > > Dear Christian, > > thanks for your message. Flemming had already put > me on the right track. He explained that my test program did not > need any references to the revisions themselves. I removed them and > the program worked fine just with the > fCalibration->Use("Pedestal") stuff. > I have set my BrRdoModuleZDC as you suggested. My question is now > can I just test the module on some data or do I need to put a > runInfoManager->Update(); > calibManager->Update(runInfo->GetUnixStartTime(), > somewhere? Depends on how exactly you execute your modules. If you use the BrMainModule and TestMainModule (as I strongly suggest you do, see my brahms_app area for loads of examples), then I suggest you take out the class I wrote (DbUpdateModule), compile it into a shared library load it into your configuration script and put it at the end of the module pipeline. The Elisp functions I posted the other day may be very useful to you in doing this. If, on the other hand, you have your hand-written program with your own event and run loop, like int main (int argc, char** argv) { // Options BrAppOptionsManager* optionManager = BrAppOptionsManager::Instance(); optionManager->SetCommandLine(argc, argv); BrAppIntOption* runOption = new BrAppIntOption('r', "run", "Run number", 0); optionManager->AddOption(runOption); if (!optionManager->ProcessCommandLine()) return; // Setup BrModuleContainer* container = BrModuleContainer("main", "Main Module Container"); ... container->Init(); while (runs-- > 0) { container->Begin() { while (true) { // Event processing ... } container->End(); } container->Finish(); } which I strongly recommend against, then you can just expand that to int main (int argc, char** argv) { // Options BrAppOptionsManager* optionManager = BrAppOptionsManager::Instance(); optionManager->SetCommandLine(argc, argv); BrAppIntOption* runOption = new BrAppIntOption('r', "run", "Run number", 0); optionManager->AddOption(runOption); if (!optionManager->ProcessCommandLine()) return; // Managers BrRunInfoManager* runManager = BrRunInfoManager::Instance(); BrRunInfo* runInfo = runManager->Register(runOption->GetValue()); BrParameterElementManager* calibManager = BrParameterElementManager::Instance(); // Setup BrModuleContainer* container = BrModuleContainer("main", "Main Module Container"); ... container->Init(); runInfoManager->Update(); calibManager->Update(runInfo->GetUnixStartTime(), while (runs-- > 0) { container->Begin() { while (true) { // Event processing ... } container->End(); } container->Finish(); } One reason why I recommend against having user defined programs as the above, is that you are not forced to follow the interface laid out by the core classes of BRAT. However, using the BrMainModule class, and TestMainModule, your classes _must_ adher to that interface, thereby forcing you to write sound classes. Put another way: If your class does not go well with TestMainModule, then it's not a BRAT class! Also, note that the converse is not nessecarily true. Another reason why I promote the use of TestMainModule, is that it will be soooo much easier to use one and anothers programs, since you really only need to have the configuration file, and no recompilation is normally needed. Also, it's much easier to add user defined analysis/calibration/... modules into a program: You just load it! No need to recompile any program. Fianlly, the CRF goes well with the design idea of TestMainModule. In a way, a configuration script for TestMainModule is much like a Kumac file for a GBRAHMS simulation: It says what the program should do, but leaves the actual execution up to TestMainModule. Ofcourse TestMainModule is much more flexible than GBRAHMS. 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 : Thu May 24 2001 - 11:41:46 EDT