Hi Flemming et al, On Wed, 30 May 2001 21:04:22 -0400 "Flemming Videbaek" <videbaek@sgs1.hirg.bnl.gov> wrote concerning ": calibrations pacakges": > First, I seems nicely done following the conventions laid out, thge > description in the README together with the Brat Guide should bring > all of this stuff well along. Something like this could go into "The BRAT Guide". > > This done let me come to the comments. > > - You do not describe (or I did not find it) the default Policy for > the parameters; I will suggest than unless there are good reasons > otherwise we should pick policy=-1 (i.e. if a given period is not > there pick the nearest previous valid calibration) The rationale is > we do not necessarely want to calibrate all parameters for each > single run. > Any comments to this? Always choose a policy. > Options to the variuos programs: > I have now noted that we are defining these options in many > utilities and even though there is overlap it is not utterly > consistent. > We need to revisit these by comparing proposal for such in > a) this calibration program > b) The DbApp used to defined detectors > c) good defaults for Config.C files. For the last part, if you use Elisp brat-config-skel, you'll be pretty much sure you always get the same options. > My suggestion is to assemble in a table what has been used so far > and come with a proposal to define a minimum set that ALWAYS with > the Brat analysis has the same meaning e.g. -i == inputfile name > -o==output filename. Such a list could ans should be made and be in "The BRAT Guide". > -- The DB access programs > > -- ReadDbTof. > > -- Big Q (1) Why do you have any Db specific access inside this > program. ... I haven't looked at this program in detail, since it's basically a utility for browsing the database, so I really didn't care much about it. > -- RunInfo program > mIt is a fine program, I just want to point out that the > runinfo.perl script can easily do precesily the same. This is > merely a matter of taste. Perhaps a general DB browser merging something like the two apps above would be a good idea. > -- Documentation. > The README is great for getting an overview. I strongly advocate > Christians advice to state in the Module description > a) needed input > b) description of algorithms > c) produced output > This does make everybodys life easier, particular further down the line. Yes, the README file is "a good thing" but documenting the class and methods in the ROOT style is also needed. I believe Djamel is aware this and was in his TODO list. If not, it should be. > As always the comments takes up a lot, Which is good. Comments are good. Take a look at some other modules like BrRdoModuleBB - not one single comment, very VERY hard to read. I repeat: COMMENTS ARE GOOD!!!!! > but No "but" there - COMMENTS ARE GOOD!!!!! > again the overall scheme looks nice, and can serve as template for > other applications 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 31 2001 - 06:25:37 EDT