I discussed this in the video conference today but most of you
couldn't connect so I'll repeat it here.
With some prompting from Teresa, I have discovered an error in the
calibration database for what concerns some interERP constants. I
believe the problem will be relatively easy to correct and we will be
able to improve the reconstructions for some interERP pairs for some
weeks.
Each week we measure the relative offset for each *pair* of
supermodules -- but what is stored in the database is an offset for
each *individual* supermodule. This requires some fancy footwork. If
OFFSET_N1 = a and OFFSET_12 = b, we store in the database OFFSET_N =
0, OFFSET_1 = a, OFFSET_2 = b-a. This results in correct
reconstructions of TOF, though it's unfortunate that changes in the N1
behavior can affect the OFFSET_2 constant.
Suppose one week N face is turned off, so the procedure returns
OFFSET_N1 = 0, and computes OFFSET_12 = -15. Then we store
OFFSET_N = 0, OFFSET_1 = 0, OFFSET_2 = -15. The next week N face
turns on. For some reason the N1 offset is quite large -- several
hundred ns. If the calibrations compute OFFSET_N1 = 300, OFFSET_12
= -14, then the output will set OFFSET_N = 0, OFFSET_1 = 300,
OFFSET_2 = 286.
The problem occurred when there were hardware problems that
provented the calibration from working well. If the calibration
procedure indicated it had trouble producing good constants for an
interERP pair, Alice would delete the produced constants from the
output kumac. However, I either miscommunicated with her or gave
her bad advice about how to do that. If N/1 failed, she would
delete the offsets for N and 1. If that happened in the example
above, we would have the updated OFFSET_2 = 286 in the database,
but the old OFFSET_1 = 0. This causes 1/2 reconstructions to be in
error by 300 ns. This actually happened with this magnitude of
error a couple of times, and smaller errors happened many other
times.
Alice has mailed me information on some of the constants which she had
deleted from the default database. I restored them in a test database
here at Caltech, and I was able to get good 1/2 reconstructions for
run 8469 -- a period during which the current default constants give
bad reconstructions for 1/2. After I get all the information on
deleted constants from Alice, I will prepare an update kumac to fix
the database.
Bob