Hi Djamel, On Thu, 24 May 2001 23:43:58 +0200 (CEST) Djamel Ouerdane <ouerdane@nbi.dk> wrote concerning ": tof calibration": > Hi all, > > I would like to inform people that I've updated the tof software. > Several new classes were created for the calibration: > > BrTofCalibrationPackage <--- container (for the 3 detectors) No no no. Do not make a module (or package) for all 3 detectors. It's really up to the user to decide how many detectors should be analysed, not you. Also, it's simple enough to do in a configuration script: //__________________________________________________________________ // Module: BrTofLaDiDa BrTofLaDiDa* tof1LaDiDa = new BrTofLaDiDa("TOF1", "TOF1 Analyser"); mainModule->AddModule(tofLaDiDa); //__________________________________________________________________ // Module: BrTofLaDiDa BrTofLaDiDa* tof2LaDiDa = new BrTofLaDiDa("TOF2", "TOF2 Analyser"); mainModule->AddModule(tofLaDiDa); //__________________________________________________________________ // Module: BrTofLaDiDa BrTofLaDiDa* tofwLaDiDa = new BrTofLaDiDa("TOFW", "TOFW Analyser"); mainModule->AddModule(tofwLaDiDa); > BrTofCalibrationModule <--- container (for 1 single detector) This is you package. Remember, any module that contains other modules is a package, _not_ a module. > BrTofPedestalModule > BrTofAdcGainModule > BrTofTdcOffsetModule > BrTofSlewingModule It's imparative that these modules read and write to the passed BrEventNodes. > BrTofSaveCalModule <--- module to save / commit calibration > (this might sound useless but we > can discuss it after people check it) I'd like to see that module. > BrTofCalibration <--- parameter element class Good. > The dialog with the DB (via parameter element and runinfo managers) is > done in the package class. No no no, again, the package is not the place to do that. All modules that need calibration parameters should ask for them directly. And finally, no module should really need to know about the run, except perhaps the track matching modules, since the magnet fields are in the run information. > All you have to use is the package class. Nothing else should be used (the > other classes are internal to this package) ... Argh. The piont of the modules is that the user may herself decide what to use and what not to use. Therefore, all modules (unless they are base classes) _must_ be useable in some form or another. What you did is exactly the same thing as what was done in the TPC tracking code, and which I previously have pointed out is errounous. > ... since the class package allows the user to turn on 1, 2 or 3 > detectors and set the calibration type (SetTof1On(), SetTof2On(), > SetTofwOn() and SetProcess("<calibration type>") Again, your package should be for _one_ detector, not all 3, and users may select via adding the appropiate modules to the module pipeline. And what do you with "calibration type"? Is that the revision type you are refering to? If so, please go back and read my email to Micheal from yesterday. Also, if you have made something that will use different revision types, then you have clearly misused the BrDb... classes, again refer to my email to Micheal yesterday. Incidently, I updated "The BRAT Guide" after Micheals questions. Go get from http://pii3.brahms.bnl.gov/~brahmlib/brat/guide/ (could the first part of this URL be www.brahms.bnl.gov - like the way STAR, PHENIX, and PHOBOS has it?) > I made these classes in the spirit of the brat standard (a module does one > action on input data and returns data). Good, but not good enough - sorry. See above comments. Could you perhaps point out to me where your stuff is, then I'll take a look at it, and you can come see me, and we can talk about it. > I use a configuration file TofCalibConfig.C to calibrate what I need. > To use it, one has only to type > > TestMainModule TofCalibConfig.C + some options > (TestMainModule TofCalibConfig.C --help for some help) > > I had to deal with "philophical problems" regarding the parameter > revisions. But I'll give more details in a note with description and > results I get (I'll hopefully finish this weekd end). What do you mean? I think you got some mixed up here. Again see the BRAT guide. > If no one disagrees, I'll commit at least the main stuff + pedestal and > adcgain modules tomorrow. I do disagree. Come see me. > Things to come (need some tests once tdc offset and slewing are ok): > BrTofHitModule <--- for hit reconstruction > BrTofHit <--- simple data object (very similar to BrCalTof) > > BrTofPidModule <--- simple module for track-tof PID > > Other things to come (but afterwards) > BrC1DigModule <--- C1 digitization module > BrC1PidModule <--- to complete the track-tof PID in FFS Looking forward to it. 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 : Fri May 25 2001 - 04:48:14 EDT