I find this discussion as ridiculous as hell. Probably, I am missing
something important.
aki
Christopher Crawford wrote:
> 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