Notes about MVD calibrations

On November 10, 1999, I gave a presentation, based on the work of YoungGook Kim and Mike Bennett, at the PHENIX software meeting at BNL. It described our ideas for calibration databases.

As a next step, I looked at the ascii files we are currently using as "database" files. Do our proposed plans account for all of the things in our current "database"? The answer is no.

  1. MVD_bcal.dat contains a set of 5 constants for each channel in the MVD which were used to parameterize the variation of the mean energy loss with eta.
  2. MVD_cross_talk_barrel.dat contains constants giving the cross-talk between adjacent channels in the MVD barrel. At the moment, this is used to add cross-talk to the simulated "data". It is not used to take it back out. Currently, cross-talk is assumed at 1% between all adjacent channels. There is one entry for each strip in the barrel.
  3. MVD_cross_talk_pad.dat contains constants giving the cross-talk between pads whose output traces pass over top of each other. At the moment, this is used to add cross-talk to the simulated "data". It is not used to take it back out. Currently, cross-talk is assumed at 1% between all channels whose output traces pass over each other.
  4. MVD_dead_channel.dat contains a list of dead channels.
  5. MVD_noise_barrel.dat contains the expected noise (expressed as sigma in keV) for each channel in the MVD barrel.
  6. MVD_noise_pad.dat contains the expected noise (expressed as sigma in keV) for each channel in the MVD pads.
Some of the parameters we currently store in "database" files are not exactly part of the calibrations and can probably be ignored in the first pass at the problem. However, some of these parameters can not be safely ignored in the first pass.
  1. The variation of dE/dx with eta may be determined as part of the offline analysisr. We should consider how we would use it in the calibration. Can we measure it using the variation in ADC values for a given channel as the vertex position changes? Do the results belong in the database? Probably the results belong in some database, but I can see situations where this is the input to, output from, of both for the calibration code.
  2. The crosstalk in the barrel will probably be understood based on measurements made on detectors prior to assembling the MVD. So, it may be input to a good calibration procedure, but I do not think it is the output of the calibration. It is not obvious how or where we should store this. For now, I think it is one of our smaller problems, but we can not neglect it forever.
  3. The crosstalk in the pads stands more chance of being "measured" with real data and I can see some chance that it would be part of the calibration procedure. The first guess will clearly come from measurements we do in the lab. This, based on our current understanding, is a more serious problem than the crosstalk in the strips, but we may still choose to ignore it in the first pass at the problem.
  4. Dead channels need to be dealt with. We can either set up a set of flags (as the current code expects) or we can set the gain to zero in the calibration parameters for dead channels. We should decide what to do and do it.
  5. The noise in the barrel can be measured, I think it should be combined with out first proposed set of calibrations constants. Instead of storing keV = gain*(ADC-pedestal), where gain and pedestal are stored, we should store gain, pedestal, and "sigma of the pedestal". I think we need to modify our proposal for calibration parameters.
  6. The noise in the pads should also be added to our calibration database.

Currently, the geometry is constructed in Geant, via input data to Geant, and passed via a geometry table from Geant (PISA) to offline code. For details look at this ps file. The proposed solution seems to be OK for now.

Overall conclusion: I think we need to add the pedestal width to the proposed gain, pedestal calibration parameters. We also need to do something about dead channels. If we do this, we will have a useful first pass at the problem. We can refine things later?

Some random thoughts and questions that came up during the November Phenix meeting.

  • How often do we expect to update the calibrations? Do we think the updates will contain just the changes from the previous calibrations or a complete set of new calibrations?
  • What is the expected volume of the calibration info we want to store? Obviously, we must answer the two previous questions before we can answer this.
  • Where and how often dowe stored approximately static information like the Si bias voltages?

    comments to: John P. Sullivan (sullivan@lanl.gov)
    updated 16-Nov-1999