First development tests for hierarchical alignment using MPII · 2020. 6. 8. · 3 Current alignment work-flow • Currently we have an “hybrid” way to do alignment: - We try

First development tests for hierarchical alignment using MPII

06/01/2020

PF

2

Outline

• At the collaboration meeting we have shown: - A recipe to extract global alignment correction using BField Off / FEEs - MPII machinery is setup for 2019 SVT geometry and we can recover local sensors u-translations (still need to confirm that rotations are recovered properly)

• The problems come when combining the two methods: - MPII gives the same solution for the L1/L2 sensors despite the global detector corrections (opening angle, for example)

• We need a way to constrain the L1/L2 movements to “make them aware” of global structure movements => MPII constrained alignment and corrections relative to other structures are the right way to proceed (at least in my view)

• Our geometry structure is not alignment-friendly: - Sensors don’t know they are linked to U-channels nor to Support Rings, for example - Millepede corrections can only be computed for sensors, only rotations of the Support Rings were available to be accounted for

3

Current alignment work-flow

• Currently we have an “hybrid” way to do alignment: - We try to fix global movements of front (UChannelL14) vs back (UChannel57) using BFieldOFF tracks (*) (**) - We try to then align local movements using seedTracker+GBL interfaced to MPII

• This rocedure outlined here by Tim (Aug ’18).

(*) Layer 7 is dead in top, so not enough points to fit a curved track.  No, we don’t have curvature constrained fit. (**) We could also use FEEs, but some inconsistencies are found. Still work ongoing to understand them

• Pitch correction (opening angle) : • Y-offset correction: • Roll correction:  

• Yaw correction: • X-offset correction: 

• Study on MC possible misalignments that change

resonance mass vs phi angle and try to match them to data to correct top/bottom rotations

θ14x = θ57xy14 = y57

θ14y = θ57y

Δx14(y) = x14(y) − x57(y) = 0

θ14z such that Δy14(x) = y14(x) − y57(x) = 0

Collaboration Meeting '20

https://indico.slac.stanford.edu/event/380/contributions/1055/attachments/446/670/CollaborationMeetingMay_2020.pdf

4

Why global structures first?

• Illustration of possible misalignment in a telescope. • b is (a possible) solution if sub-telescopes are preferred • c is (a possible) solution if single sensors are preferred • In reality it depends of various factors including: 

- Constraints (what moves what not) - Initial sensor position uncertainty (we don’t use any information on initial uncertainty in MPII solution)

5

Why IMO the 2016 strategy won’t work

• In my opinion 2016 strategy is not optimal and I’m not sure will work 2019 easily. If it works, these are my concerns on how to make it converge:

• Conceptually the procedure is “split”: two different analyses for global and local alignment including different set of tracks, correlations between movements are neglected…

• Our implementation of local alignment doesn’t know that global structures are aligned first: - Will still try to minimise the unconstrained no guarantee that this is the correct solution and local alignments can move globally, i.e. all stereo move in positive u => global X movement of a Uchannel.

• Relies on very precise starting point: - Survey correctly applied, for example

• GBL is a “local” refit, if you move the UChannelL14 wrt UChannel56, residuals and kinks on the new thin layers are mostly un-affected

• There is no-guarantee that we remove weak-modes, i.e. fixing a global x-offset can lead to momentum bias. There is no constraint on that. As well I don’t see any constraint on other track parameters.

• There is no metric that we are actually minimising.

χ2

y

topOpening angle can easily fix the z-dep

nominal geo

opening angle corrected

6

Why IMO the 2016 strategy won’t work• In my opinion 2016 strategy is not optimal and I’m not

sure will work 2019 easily. If it works, these are my concerns on how to make it converge:

• Conceptually the procedure is “split”: two different analyses for global and local alignment including different set of tracks, correlations between movements are neglected…

• Our implementation of local alignment doesn’t know that global structures are aligned first: - Will still try to minimise the unconstrained no guarantee that this is the correct solution and local alignments can move globally, i.e. all stereo move in positive u => global X movement of a Uchannel.

• Relies on very precise knowledge of module positions starting point: - Survey correctly applied, for example. This needs to be fully reviewed together with who has done it.

• GBL is a “local” refit, if you move the UChannelL14 wrt UChannel56, residuals and kinks on the new thin layers are mostly un-affected

• There is no-guarantee that we remove weak-modes, i.e. fixing a global x-offset can lead to momentum bias. There is no constraint on that. As well I don’t see any constraint on other track parameters.

• There is no metric that we are actually minimising.

χ2

opening angle corrected  + L1L2

y

top… and can be reintroduced just aligning L1L2

nominal geo

Collaboration Meeting '20

https://indico.slac.stanford.edu/event/380/contributions/1055/attachments/446/670/CollaborationMeetingMay_2020.pdf

7

Composite structure alignment

• What I would like to propose is to implement an hierarchical alignment procedure where we have alienable structures by MPII that aren’t only sensors, but also sides, modules, UChannels and SvtBox.

• This won’t solve all of our problems outlined before, but should provide: • Same way to solve global and local misalignments: just

accumulate all information and decide which structure we want to align.

• Sensor positions and orientations will be relative to composite structures and there is a natural way to include constraints to the solution.

• Composite structures will be aligned minimising the global and correlations between DoF should be taken care of.

• This procedure is a standard in solving the alignment problem and has been used successfully by other experiments.

χ2

CMS sketch

ATLAS sketch

8

Math behind composite structures alignment

• Residuals are computed in the local coordinates (q) of a sensor and transformed to global frame (r) by

• For individual sensors, alignment corrections are incremental rotations and translations which lead to

• Rotations can be reduced with respect to 3 angles. The alignment parameters become   

ΔR Δq

r = RsTq + Ts

r = RTs ΔRs(q + Δqs) + Ts

u: most sensitive direction v: least sensitive direction w: normal to the sensor plane  

a = (Δu Δv Δw α β γ)Stoye '07

https://cds.cern.ch/record/1047047/files/thesis-2007-049.pdf

9


• Each composite structure has an assigned local coordinate system defined by the orientation matrix

and origin • The definitions of the composite

structure alignment parameters is the same of the sensor alignment parameters.

• The alignment relations between sub-component to composite structure is given by:  

Rc Tc

ac

• We need to compute the C-matrices 

TransC -> TransS RotC -> TransS

TransC -> RotS => 0 RotC -> RotS => 0

relation between position/orientation corrections

relation between derivatives

10


TransC -> TransS RotC -> TransS

TransC -> RotS => 0 RotC -> RotS => 0

lever arm

C21 = 0

cmssw derivatives Stoye's thesis

https://github.com/cms-sw/cmssw/blob/master/Alignment/CommonAlignmentParametrization/src/FrameToFrameDerivative.cchttps://cds.cern.ch/record/1047047/files/thesis-2007-049.pdf

11

Constrained alignment

Stoye's thesis

https://cds.cern.ch/record/1047047/files/thesis-2007-049.pdf

12

A possible scenario of HPS Alignable structures

• Here is reported the set of orientations R and origins T (*) for possible alignable structures as it is implemented in the current HPS geometry code

• Notice: - The 30.5mrad at module level in our geometry structure  - The modules are located far from the sensors and from the support rings (large rot-to-trans cross terms in the C-matrices)

• An alignable structure is just a container of a Rotation and a translation

• C matrices can be computed in a recursive way.

• Tracking volume can be made alienable with identity rotation and null translation(*) local to global is RTq + T

13

Module to side C-Matrices examples

• As example, the matrix for the L1 top between the module (as composition of Axial and Stereo sides) and the Axial side

• Notice for axial: - Module translations are the same of axial side translations (they have the same orientation)  - Module rotations imply the same side rotation (same reason)  - Module rotations imply large sensors translations (due to the offset in constructing the geometry discussed in previous slide)

• Notice for stereo the different orientation of the sensor local axes and the stereo angle.

module to axial side

module to stereo side

14

Current status of HPS Geometry building in a nutshell

LCDD/Compact detector description

15



Formation of SurveyVolumes

Alignment corrections

Definition of transformations

Mother-daughter volumes:  - Some volumes maintain the  parent relationship - Possible to navigate the volumes and retrieve subsequent transforms

Reference volumes: - Some volumes are just place holders for transformations - Can help for survey corrections, but not possible to directly navigate through the transformations (i.e. no transformation tree is saved)

Alignment corrections are loaded and applied at this stage:  - Alignment corrections need to be added to the xml compact and parsed at this stage

HPSTrackerGeometryDefinition classes

16




HPSJavaBuilder classes

Formation of JavaSurveyVolumes

Ghost / “Physical” volumes

JavaSurveyVolumes: - Built from a selected list of SurveyVolumes - Axes location is at the center of the box: only survey volumes as boxes can be used, i.e. modules while no support rings

UChannels/SupportRingKin  not formed at all

Modules formed as ghosts sensors formed as physical

GhostVolumes:  - Basically placeholders - They don’t keep track of the underlying transformations (i.e. getGeometry() fails)

Choose what you create: - Here some of the SurveyVolumes used for step1 are dropped:  - UChannels, SupportRingsKin, SupportRingsPlate… - Some of the SurveyVolumes are physical (from alignment perspective keep the transforms) some are ghosts (they don’t keep the transforms)

17





HPSJavaConverter classes

JavaSurveyVolume to Detector  elements

Detector elements: - Are the objects directly available at reconstruction stage - Can be obtained before the eventLoop - Hold the local-to-global transformations (and bunch of other infos)

Composite structures: - There aren’t basically any composite structures down the chain - Only sensors are kept, and bunch of other things ECal/Hodo related.

RECO DRIVERS

18





HPSJavaConverter classes

Reco Drivers

Reco drivers need to retrieve composite structures transformations information to:  - Compute C-matrices and derivatives chain - Augment the GBL Trajectories with the global structure hierarchy  - Store the chain of derivatives in MPII binary inputs.

19

How I implemented this, why I sucked in doing that and how I interfaced it to MPII

• First implementation in: cAli_dev • Created AlignableDetectorElement class: 

- Way to pass the SurveyVolume transforms down to the Driver level, but mother-daughter is lost (can be re-implemented by there must be a better way without duplicating information)

• I compute the C-Matrices for each hit-on-track in the GBLRefitterDriver (sucks because it’s useless matrix multiplications for every hit. Transforms are known after geometry building )

• The interface to MPII is very simple: just add the derivatives to the GBLPoint, form a new trajectory and call milleOut. Each mille binary entry will have 6 + 6*n derivatives where n is the number of the global structures depending on that hit.

• I still don’t compute the constrains automatically but with pen and paper.

labels set

The dimension of the label set is arbitrary

These need to get recomputed for each point and a new trajectory formed

MPII manual

https://github.com/JeffersonLab/hps-java/tree/cAli_devhttps://www.desy.de/~kleinwrt/MP2/doc/html/draftman_page.html

20

Recall the single side misalignment test

• Re-alignment strategy: - Fix all outer layers  - Re-align both L1 top Axial and Stereo

• This is to check if MPII: - can recognise displacements on single side when two sides are realigned - can recover the same degree of misalignment

• Results are OK: => MPII finds that L1At is moved of 100um with sub-micron precision => MPII finds that L1St is moved of 0.8um with sub-micron precision

• Simple translations on the new thin sensors can be recovered

Single L1At movement

0.25− 0.2− 0.15− 0.1− 0.05− 0 0.05 0.1 0.15 0.2 0.25unbiased residual L1t_halfmodule_axial_sensor0 [mm]

0

0.005

0.01

0.015

0.02

0.025

0.03

0.035

0.04

0.045

0.05

hits

-on-

track

InternalHPS

TriTrig_MC_nominal

TriTrig_MC_L1tA100

TriTrig_MC_MPIICorr

0 5 10 15 20 25 30 35 40 45MPII ID [0.5-20.5 TOP 25.5-40.5 BOTTOM]

0.05−

0.04−

0.03−

0.02−

0.01−

0

0.01

0.02

0.03

0.04

0.05

bias

ed re

sidu

al m

ean

[mm

] InternalHPSTriTrig_MC_nominalTriTrig_MC_L1tA100

TriTrig_MC_MPIICorr

21

Solution in constrained alignment

• Re-alignment strategy: align 11161 (whole L1top module), 11101 ( L1 Axial) and 11102 ( L1 Stereo) tu ONLY.

• It gives the right solution: - Moves the module up of ~50um *first* (half of the stat keeps it at 0um, half at 100um and has double stat of single sensors) - Moves down the stereo angle of ~50um.  - Moves up the axial of ~50um.

• Since there is an angle of 100mrad, the stereo moves a little in this solution, but it’s at um level and tolerable.  

Single L1At movement

Only Local alignment

Global + Local alignmentSide Axial L1 Top

Side stereo L1 TopModule L1 Top

Axial

StereoModule

22

MC based misalignment tests - global movements

• Tested more complex situation:  Moved tu L1/L2top Module of +100um Moved tu L1/L2top Module of +200um

• Aligned top by freeing L1L2L3L4: - Constrain global UChannel Y movements  - Constrain global UChannel X movements

• Aligned bottom by freeing L1L2 (*) - Constrain global UChannelY

• Using the right constraints, we can relax the knowledge of the initial state

(*) Bottom is missing ly5 => issue in aligning freeing L1-L4, not enough info in the back part…

no within-module movements

correct recovery

no within-module movements

correct recovery

23

Summary and next-steps

• I’ve implemented a basic framework that uses the current geometry layout to test composite structures alignment

• I’ve validated the workflow showing that it’s possible to align composite structures and that MPII give back the right answer when the right constraints are placed, even if more degrees of freedom are released • This shows that MPII constrained alignment works • The corrections are relative to the composite structures which are now

the references • The way I solved the translation of SurveyVolumes to

AlignableDetectorElements is ugly: I would like some help to design and implement a better workflow.

• My next step is to implement and test the UChannelL14 alignment, including extending the constraint to the opening angle to the single sensors alignment and, if works in MC, apply that in data.

Documents

First development tests for hierarchical alignment using MPII · 2020. 6. 8. · 3 Current alignment work-flow • Currently we have an “hybrid” way to do alignment: - We try