Optical Endcap Alignment

Ij

Optical Endcap Alignment

From the User Perspective

Christoph Amelung

I

Outline

j

•

Where do the alignment data come from ?

•

How are the alignment data organized ?

•

What alignment data are available ?

•

How to use alignment data in reconstruction ?

I

Where Alignment Data Come From

j

•

Alignment data acquisition:

PVSS+LWDAQ data acquisition system running at Point-1 (integrated with DCS, to some extent)

takes images, analyzes them, stores analysis results in online DB (replicated to offline DB, occasionally significant delay) one cycle through all images every 45–50 minutes

→ raw alignment data (sensor measurements)

•

Alignment reconstruction:

ARAMyS reconstruction software running outside Point-1 (two separate and independent instances for sides A and C) reads sensor measurements from offline DB, reconstructs

chamber alignment

one reconstruction run every 60 minutes, always using most recent available (and valid) measurement from each sensor output: A-lines (positions/rotations), B-lines (deformations),

diagnostics (χ2 and pulls) → validation (eliminate bad runs)

→ reconstructed alignment data (A-/B-lines) stored in

I

How Alignment Data are Organized

j

•

Tags and IoVs:

an IoV (interval of validity) is the range in time for which the set of alignment data associated to it is supposed to be used a tag is an identifier describing the part of a detector

(barrel/EC-A/EC-C) which a set of alignment data is for,

plus information about the source of the data (optical, tracks, combined) and the configuration of the reconstruction program usually many IoVs are associated to the same tag, covering a sequence of time ranges; for a given time t, there may exist

several IoVs in different tags (no more than one IoV in each) think of tags and IoVs as folders and subfolders in a filesystem; alignment data then are files in the subfolders

t t t t t EC_A_TAG_XXX EC_C_TAG_XXX EC_C_TAG_YYY ... ... ... ... t

IoV #1234 IoV #1235 IoV #1236 IoV #4321 IoV #4322 IoV #4323

IoV #1238 IoV #1239 IoV #1240 IoV #4324

IoV #2345 IoV #2346 IoV #2348 IoV #2349

I

How Alignment Data are Organized

j

•

A fundamental complication:

once alignment data have been used for reconstruction, they must not be modified anymore (not even bugfixes), so that reconstruction results are reproducible forever – “tag is locked”

once a tag has been used, cannot write to it anymore (worst case: prompt reconstruction would lock a tag instantaneously)

incompatible with operation mode of alignment reconstruction: continuously keep adding new data to a tag, while old data

should already be available for reconstruction

•

The solution(s):

UPD1 tags: locked at any given moment for the past, can be unlocked for the future → to be used for prompt reconstruction (note: alignment always “lagging behind”, by construction)

UPD3 tags: similar, with some fraction of the past unlock-able as well → to be used for bulk processing after 24h

“normal” tags: unlocked until they are used for reconstruction; at that moment, create copy of “current” tag, lock and use copy → used for reprocessing (if improved alignment available)

I

What Alignment Data are Available

j

•

Twiki page of available tags:

https://twiki.cern.ch/twiki/bin/view/Atlas/AlignmentConstants

Oracle and COOL tag names, and description of what is inside (still advisable to talk with an expert to understand the details)

I

What Alignment Data are Available

j

•

Alignment data application server:

http://asap01.cern.ch:8080/atlalign/showaligniov.jsp

to list IoVs in a given tag, and read back the A-/B-lines and diagnostics (an ASCII version of this tool also exists)

I

Using Alignment Data in Reconstruction

j

•

How to use alignment data from a given tag in

track reconstruction:

good question – ask it to a software/reconstruction expert

(not an alignment expert)

•

How to make sure that alignment data from a

given tag were used track reconstruction:

several possibilities – start by checking job options and log files, look for (the COOL) tag names

the ultimate check (probably the only absolutely safe one):

download A-/B-lines for the tag and IoV that should have been used, have your ATHENA job print out the actual values s z t that it uses – and compare for a few chambers

I

What do Alignment Data Look Like

j

•

A collection of plots for the endcaps:

covering one month of cosmic data-taking (Oct 14 – Nov 11, 2009): toroid magnets switched on/off several times; chamber

temperatures mostly stable, short periods with readout off plots created by the Telomon monitoring tool,

plotting data read back from Oracle DB

http://j2eeps.cern.ch/test-atlas-muon-ecalign-javadbinterface/

I

Chamber Positions

j

I

Chamber Positions

j

I

Chamber Rotations

j

I

Chamber Deformations

j

I

Summary

j

•

Alignment data:

are available – please use them, check them, give feedback next challenge now is to keep the system stable and running

for months; do not expect big improvements in analysis and understanding of the data in the near future

•

Chamber stability:

chambers within a wheel (EI, EM, EO) move coherently;

wheels move relative to each other incoherently

EIL4/EEL1/EEL2 are not mounted in wheels, but on the

barrel toroid structure, and behave entirely different

except for magnets on/off, stability of the endcaps is closer to 100-200µm than to 40µm – limited by temperature stability perhaps the most surprising feature seen in these data: after turning magnets on or off, EIL4/EEL1/EEL2 stabilize only after 2 days – problematic for 1-day magnet-off running

I

Backup Slides

j

Bac

kup

Slides

Bac

kup

Slides

I

Alignment Corrections

j

there is a well-defined convention for communicating chamber positions and deformations to the tracking packages: the AMDB “A-lines” and “B-lines”

(historically lines in an ASCII file)

•

“P lines”:

nominal chamber positions (each line accomodates up to 8 identical sectors):

8 parameters

•

“A lines”:

corrections to nominal chamber positions (one line per chamber):

6 parameters

http://cern.ch/muondoc/Software/DetectorDescription/ amdbdoc/amdbmanual.ps

•

“B lines”:

reconstructed chamber deformations and expansion (one line per chamber):

11 parameters

I

Alignment Corrections: A-lines

j

•

Nominal chamber position

given in global system:

SZT (AMDB) is Y ZX (ATLAS)

after rotation around beam axis by 0◦, 22.5◦, 45◦, . . .

•

Local chamber system:

in the endcaps, szt (AMDB) is −xzy (μTDR), origin shifted

from central plane to first tube layer + offset

szt parallel to SZT for barrel chambers, rotated for endcap chambers (different for A/C)

•

Corrected chamber

position given in local

chamber system:

(small) shifts and rotations

I

Alignment Corrections: B-lines

j

bp and bn

bow of the tubes out of the plane, varying from the short side to

the long side

sp and sn

sag of the cross plates out of the plane, varying from the high-voltage side

to the readout side

bz

bow of the tubes in the chamber plane

ep and en

local expansions, different for the high-voltage and readout sides eg global expansion tr trapezoid-like deformation, i.e. a rotation in opposite directions of the two

outer cross plates in the plane

tw

twist, i.e. a rotation in opposite directions

of the two outer cross plates around

the tube direction

pg

parallelogram-like deformation, i.e. a rotation in the same direction of all three

cross plates in the plane

I

Alignment Corrections: B-lines

j

bn bp sp sn bz eg en/2 ep/2 tr tw tw pg ↑ these four ← are → relevant for tracking ↓ ↑ these two are relevant for r(t) calibration ↓ this one only affects cross plates, not tubes ↓

I

Chamber Deformations: B-lines

j

bp and bn rms: 60 and 40µm max: 470 and 180µm ≈ 40 EO & EML4/5 outside ± 100 µm, 5 over 200 µm sp and sn

zero (not used)

bz rms (EI/EM): 15µm max (EI/EM): 70µm rms (EO): 170µm max (EO): 560µm EO have built-in non-zero bz ep and en rms: 15 ppm max: 40 ppm eg rms: 60 ppm max: 110 ppm (1 ppm = 1µm/m) tr

zero (not used)

tw rms: 100µm max: 450µm pg rms: 390µm max: 1.7 mm

I

Chamber Positions

j

I

Chamber Positions

j

z

I

Chamber Positions

j

I

Chamber Positions

j

t

I

Chamber Positions

j

I

Chamber Positions

j

s

I

Chamber Rotations

j

I

Chamber Rotations

j

θ

I

Chamber Rotations

j

I

Chamber Rotations

j

θ

I

Chamber Rotations

j

I

Chamber Rotations

j

θ

I

Chamber Deformations

j

I

Chamber Deformations

j

I

Chamber Deformations

j

I

Chamber Deformations

j

I

Chamber Expansion

j

eg

(thermal

&

Zpitch)

I

Chamber Expansion

j

ep

(=

−

en)