Working document on alignment software

Starting discussion, S. Manly - March 1999

This is work in progress and is not intended as a real proposal for doing alignment. It is intended as something to get discussions started. It is a starting place. This folds in ideas from discussions at BNL on March 30.

Define coordinate system … standard x,y,z

define rotation angles for now (probably a convention I need to adopt. This will do for now):

a = angle of rotation around x axis b = angle of rotation around y axis g = angle of rotation around z axis

Some thoughts on alignment algorithm:

Align both the vertex detector and spectrometer internally before tying them together with vertex information.

Do top down alignment, i.e., vary larger detector elements first, work down to the smaller elements.

All movements (i.e., software corrections) must be physical. They should be consistent with that expected from the hardware design. If anything unphysical is needed, we need to step back and examine it carefully.

Vertex detector internal alignment

Top vertex detector: find vertex position on z-axis using something like current algorithm. First use course bins, then finer bins. Let this algorithm associate the hits for the layers of the top vertex detector for a given event. Preserve this association as one makes alignment iterations. Probably want to use mid-centrality events as the optimum compromise between more tracks versus more combinatorial background (must study this).

Top vertex detector: find y vertex position by measuring slope of 2d plot {(track z at z axis) vs. (track z at inner vtx layer)}

Top vertex detector: do what you can for x vertex postion. Use RHIC information if available and useful. Use top vertex detector pointing information if it is useful. Might use spectrometer information loosely. The absolute orientation and alignment of the vertex detector and spectrometer are good to some reasonable level from the design and survey. Might use x position as determined from spectrometer tracks with x position error blown up to represent uncertainty based on feasible movements within the absolute survey measurements.

Top vertex detector: remove inner-outer hit associations established above if the x position of the extrapolated track as it crosses the y vertex plane is inconsistent with x position from RHIC/spectrometer (loose) projection. There will be a broad swath of the projected track in x because of the large size of the silicon pad in x. This may not yield a useful cut.

Top vertex detector: recalculate vertex z position assuming the x and y positions above, i.e. make plot of projection of each inner-outer combination projected onto axis (parallel to z axis) at x,y found above. Picking the hits contributing to the maximum bin along new axis as associated hits, does this change any of the associations as specified initially? One should reevaluate z and y vertex positions at this point.

Top vertex detector diagnostic plots useful for alignment:

(Z vertex position for tracks passing through each sensor or module - global z vertex position) one plot per sensor, one plot per module.
Same for y vertex position

Take vertex position as fixed. Run track from vtx position through hit in inner layer. Extrapolate to outer layer and find residual for extrapolated track from actual associated hit in z. Plot the average residual as a function of vertex Z. Is this somewhat sensitive to absolute positions of inner and outer?

Alignment of top vertex detector internally:

For each track, have two hits and the vertex position. This is little information. It is easy to look at relative alignment of inner and outer layers. One can minimize the width of the vertex in z and y as the main criteria. Initially, vary one layer (which? Do hardware people have a preference?) in z and y to minimize vertex position error. Initially look at full inner/outer layer movements in z and y. Use diagnostic plots to see if there seems to be a problem with angles or a particular sensor. Look for a disagreement of vertex postion from given element with global vertex position (within statistics, plot residual for many events).

Do the same procedure for the bottom vertex detector.

Align top and bottom vertex detectors with respect to one another.

Is survey/design better for top or bottom or the same for both? Move one relative to the other (within reasonable hardware constraints and constraints coming from loose spectrometer information or RHIC information, if it is useful). Move to minimize (vtx z top - vtx z bottom) and (vtx y top - vtx y bottom). Vary z, y, b , g and I expect the error in x to be rather large at this point, so I doubt it will be terribly useful.

Is it possible to use cosmic rays to align top and bottom vertex detectors?

Spectrometer internal alignment

Align spectrometer internally:

Use field off data. Study usefulness of high p tracks with field on.

It may be necessary to do the alignment with two samples. One might use field off to get at the parts of the detector with a relatively open face toward the vertex region and then use field on data (with field off alignment information folded in) to get at parts of the detector that have a large angle with respect to the vertex position.

Use field off data. Find tracks and make a fitted track. Now, for each relevant detector element, create the residual plots of {(hit postion-fitted track position)=delta x} and {delta x vs. x} using data from many tracks. Do the same for y. Shift the position of each plane to zero out the average residual plots. Iterate until average residuals are zero. The {delta x vs. x} plot is a very good diagnostic for looking at the need for angular shifts. Delta x vs. dx/dz might also be useful to see warping and angular shifts.

Use the best geometry (with survey information) as the starting place. Get associated track hits and fitted tracks from the standard tracking code. Then feed this information into a standalone alignment routine that can evaluate shifts and create new fits and iterate as needed. It should also make diagnostic plots.

Not clear whether or not it is best to start with cooling frames or modules. With shifts of cooling frames it is best to see what is happening physically and how it relates to hardware constraints. Starting at the module level, full cooling frame shifts can be taken out as well, but it might be harder to see what is happening. I'll probably start at the module level.

Spectrometer/vertex detector relative alignment

Align spectrometer and vertex detector

Use field-off data

Project straight line tracks back from spectrometer to I.P.

Is it just as good to use field-on data and front-end of spectrometer only? Could choose high momentum tracks then.

Need somewhat high multiplicity events to get enough tracks projected back for reasonable error event-by-event.

Without additional information on transverse position of RHIC interaction diamond, constrain vertex position to x=0? Actually it might be better to use z and y info from vertex detector to align spectrometer to the vertex detector, then use spectrometer position to determine vertex position in x.

With tracking information from spectrometer, project tracks back and determine 3D interaction point as best as possible for single event.

Find the residuals, (spectrometer vtx z - multiplicity vtx z) and (spectrometer vtx y - multiplicity vtx y)

Using many events, minimize these residuals varying the six orientation parameters of the spectrometer as a fixed unit. What are constraints?

Now, on an event-by-event basis, one can get the vtx x position and the vtx x postion error from the spectrometer. I expect this is better than that coming from the vertex detector (but have not shown this).

Questions for software people:

What is Krakow thinking about the vertex finding algorithm? What is the timescale?

Spectrometer alignment and vertex x position determination are tightly coupled.

How to get at the geometry/alignment constants? How to feed alignment information back into the system?

How to run straight line tracking and get at the data? Mostly settled with Inkyu's help now.

How to feed variations of position constants into the package and rerun tracking?

Advice for how this stuff all fits in Phobos software globally, C++ thinking and all that.

Need field off data with varying IP position (in x,y,z).

Questions for hardware people:

What detectors, layers, fixtures are best known and constrained?

Which elements of the detector should be allowed to move and in what ways?

Which elements of the detector should be thought of as constrained?

What points should everything else be pinned to?

Get detailed, current detector maps.

Should one pin the spectrometer to the multiplicity detector position or vice versa, or do both get pinned to something else? If so, what? How does it relate to data fine-tuning?

Can we use cosmic rays for aligning the vertex detector?

Is survey/design better for top or bottom vertex detector or the same for both?

Questions for both:

How will alignment constant an survey constant databases work?

Who will put survey information into a software useable form?
Can we use cosmic rays for aligning the vertex detector?

Questions for RHIC:

Once a stable orbit is established, how well, independent from our detector information, does RHIC know the transverse position of the interaction diamond?

Studies:

What centrality events should be used to do alignment of vertex detector? Alignment of spectrometer?

How do the layer-to-layer hit misassociations scale with the centrality for the vertex detector?

Usefulness of field off data versus high momentum tracks in relatively low multiplicity events for spectrometer alignment?

Does one get useful hits in all parts of the spectrometer with field off data?

How much data is needed in each segment of the spectrometer?

Should one constrain the vertex position in z for tracks used for aligning certain parts of the spectrometer in order to minimize angle of incidence with respect to normal and increase number of tracks incident in detector elements?

Can one use multiplicity asymmetry in the octagon along with vertex detector z info to get some information on the transverse I.P. position on an event-by-event basis?

Can one use multiplicity asymmetry in the octagon along with vertex detector z info integrated over many events (assuming a stable orbit) to get information about transverse location of RHIC interaction diamond?

Examine possibility of aligning vtx detector with cosmics.

How well can one determine x vertex using track pointing from vertex detector alone?

What centrality events are optimal for alignment of vertex detector (more tracks versus higher background)?

Current project:

Get code from Inkyu up and running with field on data. Modify into kernel of alignment/diagnostic program. Concentrate on diagnostics.
Create bank of diagnostic histograms for all segments of the detector
Look at number of hits in each segment of the detector versus centrality.