Hi Christian, There is a subtlety here that I'm clearly missing. Do you envision a disconnect between a specific run and the corresponding calibrations? I suspect I keep trying to do something outside of the brat framework because I'm missing how you envision the code being used. Could you give an example of the situation: "Imagine what happens if you certainly start reading in at two places in the code - unbeknownst to your modules, they could very well have the wrong calibrations. " I'll make the changes that you suggest later today since I'll need to make corresponding changes to my configuration script. I'll also be expanding the number of "calibrated" runs over the next couple of days. However, the 4640 calibration should be good (pedestals, gaps, gains, etc.). I am still seeing some small differerences in my centrality cuts compared to what Hiro has and so this is also something that Hiro and I need to resolve. ...steve Christian Holm Christensen wrote: > Hi Steve, > > On Mon, 12 Nov 2001 09:42:31 -0600 > "Stephen J. Sanders" <ssanders@ku.edu> wrote > concerning "brat tag 21-1-27, mult classes updated": > >> Hi, > >> I've just made a number of modifications to the multiplicity and >> centrality classes to incorporate a 200GeV calibration. I have also >> updated the ZDC classes to add the cfd methods that Hiro has worked >> on. Since the ZDC modifications change the date structure (with the >> addition of a cfd vertex), I have bumped the ClassDef for BrZdcRdo >> to 4. Although the CFD ZDC vertex has a broader distribution with >> respect to the TPM1 vertex, it is found to be more reliable at low >> ZDC multiplicity since there is less of a slewing correction. For >> the multiplicity calibration we only use the zdc vertex when a BB or >> TPM1 vertex can not be found, so the slewing correction is a >> significant issue. >> >> The si/tile/mult classes now all look for a run number from the run >> manager in their Init methods. They should be selecting a >> reasonable calibration depending on run number. > > > Argh! Modules should not, I repeat not, look for calibrations > themselves! They must, I repeat must, assume that all calibrations > are as they should be, otherwise chaos and mayhem will quickly insue! > This is due to the fact that calibrations are managed, and as such, > Modules can not, and must not modify that data! Imagine what happens > if you certainly start reading in at two places in the code - > unbeknownst to your modules, they could very well have the wrong > calibrations. > > So far, the calibrations for the TMA and SMA have been read from ASCII > files installed in <prefix>/share/brat/params/mult, even though the > calibrations for last years data has been in the database for quite > some time now. When you you commit the 2001 calibrations to the > database, we should immidiatly switch to that interface and remove the > old, useless, ASCII files. > > The proper way to do things for the time being, using the ASCII files, > is to read the ASCII files from your configuration script. This > works, since the temporary calibration classes are singletons. Hence, > you should have in your configuration script > > BrSiTmpCalibration::Instance()->ReadASCIIFile(runOption->GetValue()); > BrTileTmpCalibration::Instance()->ReadASCIIFile(runOption->GetValue()); > BrMultCentTmpCalibration::Instance()->ReadASCIIFile(runOption->GetValue()); > > If you're still not using configuration scripts (sigh), then you need > to put these lines into your program somewhere. > > I will change the classes so that they do not read the ASCII files > themselves ASAP. I will ofcourse announce that on the list. > >> For the 200 GeV data, the calibration is taken from run 4640. I >> will be adding calibrations for the later runs as soon as possible. > > > Am I to understand, that the pedestal, pedestal width, gap, pulser, > and gain calibrations in that file is good? If so, I'll start an > SDE centrality calibration ASAP. > >> However, let me know if there is a specific later run for which you >> need a centrality and I try to develop one. In general, I believe >> that only the pedestals are likely to shift significantly >> run-to-run, although there have been isolated cases of detector >> element going bad. > > > Erh, shouldn't we at least check that all the parameters are stable? > > Yours, > > Christian Holm Christensen ------------------------------------------- > Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 > DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 > Denmark Office: (+45) 353 25 305 > Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b30 : Tue Nov 13 2001 - 10:13:38 EST