From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Tue Aug 19 2003 - 05:46:24 EDT
Hi Flemming, Sorry that I didn't answer sooner. Loads of things to do these days, and very little net-access :-( "Flemming Videbaek" <videbaek@sgs1.hirg.bnl.gov> wrote concerning calibration validity periods [Thu, 14 Aug 2003 10:32:49 -0400] ---------------------------------------------------------------------- > As you may have seen Hiro is making the basic calibrations for BB, > Inel counters etc for the dAu and pp run-3 data. While discussion > this with Hiro i.e. checking what calibration did already exist I > will remind you all about the methid the DB uses, and a concern > about potential calibration issues/conflict in the DB. > The DB was designed (briefly the following way) when finding a valid > calibration. > a) If one or more calibration exists for a given RUN (in fact time) > say 8060 e.g the newest one will be picked. What doies it mean a > calibration exists- it means that the validity period of the > calibration i.e. validStart to validEnd overlaps the run/time asked > for. Assume you have the following situation > > --rev 1) start 8040 end 8080 > --rev 2) start 8060 end 8060 > > When asking for run 8060 you will get rev2) as you expect. One > the other hand if you ask for 8061 you will get 1) since there is > only one calibration with overlapping validity period. On the > other hand if you ask for 8081 you will get rev2) since this is > the newest with the nearest validity time. Are you sure about the case for 8081? It should choose `rev-1' as it's the one with the closest `endValid' time. That is, it orders after `endValid' first, then age. If not, there's an error. > Now why does this matter - you will say calibrations are only > inserted for a given run, or possible with a short number of runs > e.g in the case of slewings where multiple run are used. Thats > is waht one will hope for- butthis is not the case. > What we found were e.g. a calibration for BB slweing covering the > run period 7000-8465. Since the new cal are only done for > selected runs one would not get the correct calibration, but this > specific one inserted with a very long validity period. To > resolve the problem we can either a) change the algorithm for > picking the calibration to always look for the nearest and newest > one, as is in fact done in the script in the DAQ page telling you > about . > > b) modify the validEnd in calibration committed if they are clear > too large? and That should be done no matter what. Over eager calibrators are at fault in this case. > c) MAke sure when you commit new cal they are for single run's only > !!! Hmm. That doesn't make sense. The point of having a long period, is often to say: `I strongly believe this is steady'. If, however, you later on find out, that at some specific point, it wasn't as steady, you can insert an new revision for a smaller period, that will be picked. So long validity periods are sort of `default' values, and good for Quick'n'Dirty (Quirky'n'Defunct) calibrations that some of our collaborators like, especially close to QM :-) > Thus this is also a warning to commit calibration only for one RUN > and not for an extended period. Logically if you make say a > calibration from multiple runs the natural period is from first run > to last run used. Unless, of course, you actually test your calibrations on an extended period, and find it to be good. In that case, the logical period is larger than the one you used for the actual calibration. > Looking specifically what I seen in the DB is that some older > calibration too exists than run over long periods which were > committed quite early in the DB. Over optimism! > example: BB slewing has one ancient cal(for slewing) the covers > 3995->5320 and another that covers 5336-> 5581 with about 18 newer > revisions in that range. I will thus suspect that some runs > e.g. between 5366 to 5581 has been using the old calibrations and > not the newer and presumably better except for the specific runno > where the calibrations was done. We talked about chopping up validity intervals when we designed the DB. But AFAIR we abandoned the idea, as we (Flemming, Konstantin, Kris and I) seemed to think it redundant. I can't remember our reasons, but perhaps a glance at the design documents will be of some help. Yours, ___ | Christian Holm Christensen |_| | ------------------------------------------------------------- | | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 _| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91 _| Denmark Office: (+45) 353 25 305 ____| Email: cholm@nbi.dk Web: www.nbi.dk/~cholm | |
This archive was generated by hypermail 2.1.5 : Tue Aug 19 2003 - 05:46:58 EDT