User name Templon
Log entry time 22:28:56 on October 6,2000
Entry number 49571
keyword=corrected time notesI spent most of the day today trying to work on coincidence time
optimization -- we cannot see the coincidence time peak in
kinematics PY-1F.
.
The espace documentation is hideously, hideously broken on this point.
Also, the beta optimization according to nilanga has not been working
for four years, so it should be removed from the code, from the manual,
and from all kumac files. Finally, the structures are nested so deeply
inside the code that it is nearly impossible to figure out what the hell
it is doing to correct the coincidence time. There should be, somewhere
accessible to the public, a concise description of EXACTLY how
tc_cor is calculated (without using espace "structure" notation --
use english).
.
I took the seat of the pants method: I was told by two experts that if beta
is optimized, then tc_cor is also optimized. I managed to find in the
source how beta is calculated, and it uses some corrected tdc values for
the scints. I then made a run to plot a) the raw tdc values and b) the corrected
tdc values. I convinced myself that the corrected tdc values were very close
to the raw tdc values minus the offsets (this is for the electron arm). I
then computed new tdc offsets which were designed to line all the S1
tdcs on the e- arm at channel 2000 in the corrected spectrum. Doing this
had a definite positive effect on tc_cor ... I did not save a picture from
the "virgin" database, but it had three peaks. Fig. 1 below has only two
peaks. So this is at least a "fairly" correct approach. We will most likely
not have the correct beta spectrum but so what.
.
well this worked for the electron arm but it is not so simple for the hadron
arm. there was no obvious relation between the hadron database offsets, and the difference between the uncorrected and corrected tdc times. i am giving up for the evening. i will also note one strange
phenomenon which probably is actually a clue to solving the problem,
but i am too tired to think about it any more. in going to corrected
time, for some reason a second peak develops. here for example
(fig. 2) i show (top panel) uncorrected S1-2L time in proton arm and
(lower panel) corrected S1-2L time. Note the second peak.
.
a couple more notes:
1) my database (that has the "correct" S1 offsets for e- arm) is in "db_jeff"
2) there was a note somewhere about if (full_database) then ...
... and in that if block (in the code for espace), S3 was being used. I notice
... that the hadron part of the database DOES have a block for S3, but
... I did not attempt to yank it out. The espace manual description of the
... database does not mention anything about this (and actually the espace
... manual description of the data base is incomplete in most places,
... so it is very hard to know what one is doing). BUT if for some reason
... espace was really trying to use S3 to correct the time, this would certainly
... explain why tc_cor was broken.
FIGURE 1
FIGURE 2
