Hi Micheal, I'm sending this email to the brahms-dev-l list since it may be of general intrest. I'm afraid it's rather long, but please take the time to read it, since I'll explain some important points on the Database issues. On Wed, 23 May 2001 09:02:22 -0500 Michael Murray <murray@CyclotronMail.tamu.edu> wrote concerning ": Database access from rdo module": > Dear Christian, > I have managed to read and write ZDC data into > the database. (I used Djamel's standalone code as an > example.) Connection to the calibration database, is done by putting in your setup section of you configuration script: // Database connections BrMainDb* mainDb = new BrMainDb(0, 0, mainDbHostOption->GetValue(), mainDbNameOption->GetValue()) mainDb->ConnectToCallib(); mainDb->ConnectToRun(); // Calibration and Run info managers BrParameterElementManager* calibManager = BrParameterElementManager::Instance(); BrRunInfoManager* runinfoManager = BrRunInfoManager::Instance(); // Register a run number BrRunInto* runInfo = runinfoManager->Register(runOption->GetValue()); > However I now need to access the database from the the ZDC Rdo > module. I found an example of how this was done in the tile Rdo > module. To access calibrations from a module, you must have in the Init method of your module: BrParameterElementManager *calibManager = BrParameterElementManager::Instance(); fCalibration = static_cast<BrTileCalibration*> (calibManager->Register("BrTileCalibration", BrDetectorList::GetDetectorName(kBrTile))); if (!fCalibration) Failure("Init", "didn't get calibration from manager"); // Tell the manager which parameters this module need. // Below is an example. fCalibration->Use("pedestal"); Then in your Event method, you may use the fCalibration pointer directly to get the calibration numbers. > In this code there are no references to the particular "REVISIONS" > defined for the tiles. Somehow these must go in another module. Do > you know where I should put this for the ZDCs? I hope you realise that the point of there being absolutly no reference to a _particular_ revision in the RDO modules is the whole point of all this. You see, it's the job of BrParameterElementManager to serve the calibration numbers (viz, the particular revision) to whom ever may need it. In that way, you can make sure every module uses the same numbers. That means, that it's the job of BrParameterElementManager to make sure that all calibration parameters are up to date and consistent across modules. So what happens is this: For any calibration parameter registered (via BrParameterElement::Use(name)), BrParameterElementManager will automatically fetch the right revision for the time period (i.e., run) under consideration. The update is achived, by having the lines below runInfoManager->Update(); calibManager->Update(runInfo->GetUnixStartTime(), runInfo->GetUnixEndTime()); This will make BrParameterElementManager look at all registered parameters and then update those to the have the right values for that run (time-period). These two lines _must_ be executed after the Init of all modules, so we need to put it into a module. However, we may also want to switch runs at Begin time of the module pipeline (see the BrModule and BrModuleContainer class description for more information), so out module should also have the cabality to update in the Begin method. All in all, the module would be some thing like class DbUpdateModule : public BrModule { public: enum EJobType { kOneRun, kManyRuns }; private: EJobType fJobType; void Update() { // Calibration and Run info managers BrParameterElementManager* calibManager = BrParameterElementManager::Instance(); BrRunInfoManager* runinfoManager = BrRunInfoManager::Instance(); // Get a pointer to the Run information. BrRunInto* runInfo = runInfoManager->GetCurrentRun(); // Update the run information and all requested calibration data runInfoManager->Update(); calibManager->Update(runInfo->GetUnixStartTime(), runInfo->GetUnixEndTime()); } public: DbUpdateModule(const char* name, const char* title) : BrModule(name, title) { SetJobType(); } void SetJobType(EJobType type=kOneRun) { fJobType = type; } void Init() { if (fJobType == kManyRuns) return; Update(); } void Begin() { if (fJobType == kOneRun) return; Update(); } Class(DbUpdateModule, 0) // Update db information }; Such a class should probably be in BRAT. The class should ofcourse all take care of updating the geometry data. The matter of different revision types is not entirely resovled as of now, and there's no way at the moment to specify a specific revision type in the user code as of yet. However, I imagine that we could extent the method BrParameterElement::Use(const char* name) to be BrParameterElement::Use(const char* name, const char* type) and then one could in some user defined module change the revision type one want's for a given parameter: class MyTypesModule : public BrModule { private: TString fDetectorName; TString fParameterName; TString fRevisionType; public: MyTypesModule(const char* name, const char* title) : BrModule(name, title) SetCalibName(const char* name) { fCalibName = name; } SetDetectorName(const char* name) { SetName(name); } SetParameterName(const char* name) { fParameterName = name; } SetRevisionType(const char* name) { fRevisionType = name; } void Init() { BrParameterElementManager *calibManager = BrParameterElementManager::Instance(); BrParameterElement* calibration = calibManager->Register(fCalibName.Data(), GetName()); if (!calibration) Failure("Init", "didn't get calibration '%s' for '%s' from manager", fCalibName.Data(), GetName()); calibration->Use(fParameterName.Data(), fRevisionType.Data()); } ClassDef(MyTypesModule, 0) // Flag a calibration parameter to of a type }; And then one can add arbitrary many such modules at the end of a module pipeline: gSystem->Load("MyTypeModule.so"); MyTypeModule* tilePedFooModule = new MyTypeModule(BrDetectorList::GetDetectorName(kBrTile), "My rev type"); tilePedFooModule->SetCalibName("BrTileCalibration"); tilePedFooModule->SetParameter("pedestal"); tilePedFooModule->SetRevisionType("foo"); mainModule->AddModule(tilePedFooModule); MyTypeModule could be in BRAT, and users could ofcourse define packages to load in to the configuration script and add to the pipe-line, like above. 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 - 10:51:25 EDT