Hi Doug and Michael,
I have to agree with you. For instance, looking at the plots, I'm
not convinced that the offsets improved overall. It was probably far
too preliminary to present, but I was under pressure to produce
results, and this is as good a starting point as any. The only thing
I am absolutely sure that works is the geometrical transformations
(and the overall technique).
--Chris
On Mar 28, 2006, at 10:06:20, Douglas Kenneth Hasell wrote:
> Hi Chris,
>
> It's excellent that you have done this but I have some problems
> with the results of your fits.
>
> The first set had offsets of 2.6 and 2.8 cm !!! in the vertical.
> If these were mm I could maybe go along with them but there is no
> way this can in cm. Similarly the X offsets were .5 and .26 cm
> which are also much too large to be physically compatible with the
> surveys. The angle offsets are fine. The second analysis is a bit
> better in X and Y offsets but still too large.
>
I have to make sure the derivatives make sense first, before asking
if the results are plausible. I'm resurrecting Tim's implementation
of the TMinuit track fitter, to compare with my own fitting. It
might just be that TBLFitTrack::AdjustTracks is changing the hits
half way during the derivative and screwing it up.
> When doing such fits you need to weight the contributions from the
> spacial offsets and angular offsets. What weights do you use? I
> think a tolerance or uncertainty in spacial offsets of 0.1 or 0.2
> cm would be fine ie. a change of 0.1 cm is one STD. For angular
> offsets I think 1 STD corresponds to about 0.5 degrees.
Recall that in a least-squares fit, only the response parameters are
weighted, not what you are fitting for. I used the standard BLAST
resolutions to weight each of the kinematic offsets. As Michael
points out, there is a way around it, to look at the covariance
matrix, specifically the eigenvectors. There will be some linear
combinations of parameters for which there is minimal response, so
the fitted value can vary wildly within error. The only reasonable
thing to do is to zero them out. But I'm still not getting the
obvious null eigenvectors, like translations in z or phi.
>
> What do others think?
>
> Maybe you can search just over the angular offsets and see what
> improvements arise.
Sure, this would be an easy option to add.
>
>
> Cheers,
>
> Douglas
>
> 26-415
> M.I.T.
> Tel: +1 (617) 258-7199
> 77 Massachusetts Avenue Fax: +1
> (617) 258-5440
> Cambridge, MA 02139, USA E-mail:
> hasell@mit.edu
>
> On Mar 28, 2006, at 11:35 AM, Christopher Crawford wrote:
>
>> An update and first results on the geometrical offsets of the WC:
>>
>> GEOMETRY:
>>
>> The libraries TBLGeomWC and TBLGeometry have been updated to allow
>> for rigid body transformations of either the entire left sector or
>> right sector WC, through the 'blastrc' resources:
>>
>> GeomWC.LeftOffset: 0,0,0,0,0,0 # adjustments to left and right
>> sector
>> GeomWC.RightOffset: 0,0,0,0,0,0 # X,Y,Z(cm), alpha,beta,gamma(deg)
>>
>> or their command-line equivalents "GeomWC.LeftOffset=0,0,0,0,0,0",
>> etc. For Instance, this can be added directly to the autocruncher
>> COMMAND. Be sure to put no spaces between the commas, as this
>> will confuse both the command-line interpreter and the parsing of
>> the offsets. As an aside, also do not include comments on lines
>> with strings, as they will be included in the string!
>>
>> The angles alpha, beta, gamma correspond to CCW rotations about
>> the WC +y axis, the BLAST +z axis, and the WC +z axis,
>> respectively. For small adjustments the order or rotations is a
>> second-order correction. For example, d_alpha>0 moves the
>> downstream end farther from the beamline; d_beta>0 tilts the
>> outside edge of the left sector up and right sector down; and
>> d_gamma tilts the downstream end of the left sector down and right
>> sector up.
>>
>> Thanks, Michael, for pointing out that these adjustments cannot be
>> applied uniformly to each of the three chambers. Instead, they
>> are applied to the middle chamber, and the inner/outer ones are
>> transformed explicitly as a single rigid body. The offsets were
>> tested with the macro 'BlastLib2/test_wc_geom_adj.C', which looked
>> at the angles between 4 points in each chamber spanning 3-space,
>> before and after arbitrary transformations.
>>
>> There is also a new function TBLGeometry::AdjustWC to set them
>> further in the code.
>>
>> NTUPLE:
>>
>> I wrote and tested a post-DST processor 'BlastLib2/geomfull.cc' to
>> calculate the derivatives of each of 5 elastic kinematic offsets
>> (along with the current offsets) event-by-event, using events from
>> an elastic event-list:
>> ( p_e - p_e(th_e), p_p - p_p(th_p), th_p - th_p(th_e),
>> phi_p - phi_e +/- 180, z_p - z_e )
>> for electrons in either the left or right sector (10 offsets), as
>> a function of X,Y,Z,A,B,C in each sector (12 adjustments). A
>> sample Jacobian for one event is included below. Note that the
>> first two offsets only change for geometrical adjustments in the
>> same sector, and that d(delta_z)/d(Z) = +/-1 (at least it should)
>> for adjustment in the proton/electron sector.
>>
>> There are still two problems: First dz/dZ != 1 in the electron
>> sector. I haven't figured out what is wrong, but it may not be
>> specific to the offset corrections. The second related problem, I
>> expected two null eigenvectors corresponding to elastic scattering
>> symmetries in Z and in Phi, but found neither.
>>
>> Command: root -l geomfull_offsets.C 12673 -n 20 -csnorm +de +dp
>> +dt +df +dz +print
>> Entry 0 (run 12673, event 213)
>>
>> _L offsets + LEFT d/dx d/dy d/dz d/dalpha d/
>> beta d/dgamma + RIGHT d/dx d/dy d/dz d/dalpha d/
>> beta d/dgamma
>> pe -0.019281 0.000000 0.000000 0.000000 0.000000
>> 0.000000 0.000000 0.007016 -0.001364 0.000874 0.000943
>> -0.004461 0.002421
>> pp 0.031862 -0.006611 -0.006817 0.000285 0.023947
>> 0.008572 -0.007964 0.000000 0.000000 0.000000 0.000000
>> 0.000000 0.000000
>> tt 0.650497 -0.136070 -0.075535 0.001808 1.188988
>> 0.103065 -0.009689 -0.073448 0.032066 0.038212 0.802696
>> 0.077736 0.020897
>> ff -0.660084 0.041375 0.452306 -0.000398 -0.031691
>> 0.214961 0.493497 0.071594 0.552872 0.001038 -0.021576
>> 0.078003 0.413605
>> zz 0.464627 -0.743655 -0.096612 1.003096 3.252622
>> 0.139978 -0.139421 -1.264678 -0.076465 -1.172769 -5.258923
>> -0.207254 0.144767
>>
>> + +
>>
>> ANALYSIS:
>>
>> I also wrote an analysis script 'exp/analysis/macros/
>> geomfull_offsets.C' which fit for the WC offsets which best
>> produced the observed kinematic offsets.
>> The analysis cycle consists of Newton-Rhapson iterations of
>> creating ntuples with the kinematic offsets and derivatives for
>> the current WC offsets, doing a least-squares fit for the
>> deviation in WC offsets, and subtracting these in the next
>> iteration until convergence. The commands executed are logged in
>> 'bud11:~chris2/blast/control/autocruncher/A_config' and in the
>> header of 'geomfull_offsets.C', and the ntuples from each
>> iteration are located at 'bud13:/scratch/bud13/chris2/geomfull/
>> iter*' Taylan, the autocruncher came in real handy for this!
>>
>> Separate iterations were done for different weightings of the
>> events. Plots of the geometrically-corrected kinematic offsets of
>> each are included. The first used a flat distribution of events
>> by weighting out the cross section (see plot), resulting in
>> adjustments:
>> // GeomWC.LeftOffset=0.506,2.665,-0.008,0.089,-0.503,0.399
>> GeomWC.RightOffset=0.268,-2.824,-0.261,0.017,0.692,0.897
>> The second set used the elastic distribution unmodified and
>> heavily weights forward events:
>> // GeomWC.LeftOffset=0.031,0.568,-0.688,0.140,-0.258,0.393
>> GeomWC.RightOffset=0.188,-0.910,-0.182,0.011,0.021,0.736
>> The three plots show offsets before corrections, after flat
>> corrections, and after c.s.-weighted corrections. They don't look
>> very good yet.
>>
>> This is only a preliminary analysis demonstrating the proof-of-
>> principle. Physics offsets must be included before any hope of
>> stable geometry offsets. Also, since the fit is a simple least-
>> squares fit (using means) with no robustness added (medians or fit
>> peaks), it is very important to handle momentum, which has a one-
>> sided tail, consistently. The cuts on invariant mass must be used
>> in this program must be consistent with those used to determine
>> the radiative corrections to the momentum.
>>
>> --Chris
>> _______________________________________
>>
>> TA-53/MPF-1/D111 P-23 MS H803
>> LANL, Los Alamos, NM 87545
>> 505-665-9804(o) 665-4121(f) 662-0639(h)
>> _______________________________________
>>
>> <cs_weight.gif>
>> <geomfull_offsets_orig.gif>
>> <geomfull_offsets_flat.gif>
>> <geomfull_offsets_cs.gif>
>>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:33 EST