Output of AlignmentTrackChi2

1

Hi!

I am using allpix/corryvreckan for some small studies regarding alignment (probably something these frameworks were not meant to do in this form, but I think I can get some useful information for my use-case) and wanted to ask on how to interpret the output of the AlignmentTrackChi2 module.

[AlignmentTrackChi2]
iterations = 5
align_position = true
align_orientation = false
prune_tracks = true
max_associated_clusters = 2
max_track_chi2ndof = 10

I have sensors aligned centrally when generating events in allpix (12 pixel sensor layers, 4 “LGAD” pixel sensor layers with a 1.3x1.3 mm2 pixel pitch), and then introduce a shift of one of the LGAD sensors in the x/y plane when I feed the geometry to corry to see if/how well the alignment can correct for this error.

Allpix geometry

[lgad3]
type = “LGAD”
position = 0um 0um 2725mm
orientation_mode = “xyz”
orientation = 0deg 0deg 180deg
alignment_precision_position = 0um 0um 0um

Corry geometry

[lgad3]
position = 5mm, 5mm, 2725mm
orientation_mode = “xyz”
orientation = -0deg, 0deg, 180deg
type = “LGAD”
pixel_pitch = 1300um, 1300um
number_of_pixels = 15, 30
time_resolution = 5ns
material_budget = 0.00495371

Never mind incorrect modelling of an LGAD sensor, this is not important for this study, all I need is a sensor with 1.3x1.3 mm2 pixel pitch (for now :slight_smile: ).

Now in the console output of a first run with 10k events, I see

|11:23:42.496| (STATUS) [F:AlignmentTrackChi2] lgad3 new alignment:
T(3.34488mm,4.45746mm,2725mm) R(-0,0,180deg)

which is already rather close. Since I want to vary the misalignment and see how this behaves (so automate the procedure), I wanted to read the alignement constants from the output rootfile. But I don’t quite understand how to interpret the output TGraph of AlignmentTrackChi2, since the values I read form AlignmentTrackChi2/alignment_correction_displacementX(Y)_lgad3 are

LGAD 3
Iteration: 0 , correction valueX: -1637.34 , correction valueY: -524.172
Iteration: 1 , correction valueX: 18.9548 , correction valueY: 18.4223
Iteration: 2 , correction valueX: 18.788 , correction valueY: 18.7246
Iteration: 3 , correction valueX: 18.6906 , correction valueY: 18.7
Iteration: 4 , correction valueX: 18.6808 , correction valueY: 18.6827

How do I have to read this to get the 3.34488mm,4.45746mm values I read from the command line output?

Thanks a lot,
Alex

2

Hi @aleopold

if I understand you correctly, the alignment isn’t rather close already - your true position (as simulated with Allpix Squared) is (0mm, 0mm), so this is what should be the result of your alignment. The (5mm, 5mm) is the misalignment you introduced.

Let me first answer your question though:
The values are incremental shifts from the initial position, i.e. 3.34mm = 5mm - 1.6mm + 0.018mm + 0.018mm… Same for Y.

Having said that: a 5mm misalignment is huge and your alignment algorithm will likely fail to align the detectors in one go. That’s why we have the Prealignment module which calculates a basic residual and shifts it to zero for a start. The AlignmentTrackChi2 is then there for the sub-micron alignment precision - but I’m not sure you need this with a 1.3mm pad.

Have a look at the Corryvreckan manual, @jekroege wrote a nice overview of the alignment procedure as a reference.

Best,
Simon

3

Hi Simon,

thanks a lot for the explanations, this makes great sense! And thanks for pointing out the prealignment module, I will have a look at this. I actually want to use this setup to get a bit of a feeling for what a big (or even too big) misalignment for a geometry like this is and/or what can be recovered (and to which extent) with software alignment.

Best,
Alex

4

Hi Alex,

In the end, everything can be recovered - just with different methods. However, the worse your alignment initially is, the smaller the overlap between your detectors and therefore your active area will become.

Hence the general suggestion: get it as precise as possible mechanically, e.g. by checking chelation plots online (with Corry die example) and only fix the remaining misalignment offline.

5mm is something you should still see by eye, 1mm should appear in online data quality monitoring, and everything below is likely a job for offline alignment.

Cheers
Simon

5

Indeed, I agree that “as precise as possible” is of course always desirable. I want to see if I can get a feeling what is minimally necessary (or if that exists at all or if no matter how badly I misalign, given enough stats I can always recover the alignment by using tracks), how it maybe depends on the resolution of the position of extrapolation etc