Hi Flemming and Christian
Thanks for the comments.
I'm presently working at home on testing the other calibrations but also
correcting small things according to your 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.
>
Yes, I forgot to mention this. To create a parameter, use CreateParameter
in dbapp. AT some point, you'll be asked what policy you should set.
Choose -1.
>
> > 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.
>
I was working on some old versions and it might be that it was not created
by the elisp help.
> > 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. ...
Yes, it's an old program. At that time, I was wondering how to be sure
that a revision exists when you update the parameter element manager
between a certain starttime and endtime.
But I still have this question. I'm updating this utility (I have renamed
it TofDbBrowser) but I cannot see any method in the
BrParameterElementManager or BrParameterElement telling the user if the
revision exists between these time limits.
Would it be nice to have:
let's say fCalibration is a parameter element (e.g. BrTofCalibration)
the top pedestal parameter data was tagged for use:
fCalibration->Use("topPedestal");
then
elementManager->Update(start, end)
Bool_t isRevision = fCalibration->("topPedestal");
if (isRevision == kFALSE)
do_something;
maybe such thing exists but I cannot see where.
>
> 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.
>
Maybe. But what about these perl scripts Flemming mentions?
> > -- 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
>
Yeah, that's right. I'll put more comments at the beginning of each method
but you cannot say that my stuff doesn't have any comments :)
Flemming, concerning the fit for the pedestal, I cannot see a difference
between the histogram mean and the fit mean. About the width, there 's a
slight difference, especially when you don't select sync events.
Finally, I decided to put a trigger filter (the nice thing is that I don't
need to recompile the whole thing! I'm still really admiring all this main
module stuff, that's really neat).
Making the whole thing with a profile (like the ones I make to
summarize the calibration) would have the advantage of not
having a spate of histograms and giving more free memory but I don't know
how to
retrieve the width of the pedestal peak for each slat (getting the mean
is ok). Is there an option or something in TProfile ?? if I do
GetBinError, I get the statistical error.
Ciao
Djam
--
Djamel Ouerdane ------------------------------------------o
| Niels Bohr Intstitute | Home: |
| Blegdamsvej 17, DK-2100 Ø | Jagtvej 141 2D, |
| Fax: +45 35 32 50 16 | DK-2200 Copenhagen N |
| Tel: +45 35 32 52 69 | +45 35 86 19 74 |
| http://www.nbi.dk/~ouerdane |
| ouerdane@nbi.dk |
o---------------------------------------------------------o
This archive was generated by hypermail 2b29 : Thu May 31 2001 - 08:24:13 EDT