The code for (and code fragment resulting from) recalculating the PG chamber centers is here. It is a set of scripts to let you recreate the PG centers using Oleg's alignment Excel spreadsheets (as reduced to CSV files). The bunch of them are collected in a gz file makingYourOwnPGCenters.tar.gz
Before I forget again, I should document that if I run all 6 transfer line and look at line 1 transfer plate positions, or run on a reduced model with only transfer line 1, the positions are the same. The disk positions are fixed: all bets are off if they float.
$ grep '^CMS ' line1test.frame | grep '_tp1 ' |awk '{n=split($2,a,"/");print a[n],$3,$5}'
MEm1_tp1 6928.0049 1897.0078
MEm2_tp1 6869.4392 2128.8317
MEm3_tp1 6850.5532 2170.0367
MEm4_tp1 6836.9362 2164.8066
MEp1_tp1 6912.8995 1943.825
MEp2_tp1 6849.5789 2168.1858
MEp3_tp1 6855.6405 2122.0821
MEp4_tp1 6860.6859 2125.2373
$ grep '^CMS ' junelock.frame | grep '_tp1 ' |awk '{n=split($2,a,"/");print a[n],$3,$5}'
MEm1_tp1 6928.0049 1897.0078
MEm2_tp1 6869.4392 2128.8317
MEm3_tp1 6850.5532 2170.0367
MEm4_tp1 6836.9362 2164.8066
MEp1_tp1 6912.8995 1943.825
MEp2_tp1 6849.5789 2168.1858
MEp3_tp1 6855.6405 2122.0821
MEp4_tp1 6860.6859 2125.2373
The values still don't make complete sense.
One of the values I gave Himali for ME+1/3/28 makes no sense. I believe there is a typo in alignment_pin_database_oct31_08_v1Plus.csv as below:
ME+1/3,28,ME+1-3-28 OUTER PIN,13282,32.66,-6990.27,-792.21,0.000,-6794.492,6800.3,,,,6794.49, should be ME+1/3,28,ME+1-3-28 OUTER PIN,13282,32.66,-6790.27,-792.21,0.000,-6794.492,6800.3,,,,6794.49,
When I change this, I get the following absolute and relative XML files. Please note that if you want to save them, you should right click on the link, because the browser will interpret them.
testjnb6.xml and localjnb6.xml.
localpgonly.xml is a test file containing chamber positions based only on PG + disk rotations, where the YE3 disks are survey, YE1 disks are from Link fits, and YE2 are WAG from assembly survey which we all know is no longer valid (and I have measurements to show is wrong). pgonly.xml contains the absolute coordinate estimates.
I face a little problem: I have a second-hand file containing PG chamber positions and rotations (ideal), nominally the one the track based alignment group used. But, I'm not certain how how it was made, and when I attempt to duplicate some of the entries I don't get the same numbers. The differences aren't huge, but I'm suspecting that the entries were manipulated somehow. I want clean numbers. Unfortunately the chamber Z is messy to calculate. The X/Y is simple enough: it is along the line between the alignment pins. Average and use the direction between the pins to add on a correction of about 1cm (varies between chamber types).
Z of the alignment pins is not very accurate: the coded target position is better.
I'm not keen on reinventing the wheel at this late date, but it looks like I need to rederive the PG constants for the whole system. I already did this for ME1.
getcodedZfromCSV.awk extracts chamber Z positions from the .CSV files created from the Excel spreadsheets, and writes the results out. I specify codedZinitFRAG.cc, but that's no matter. This won't be complete, and the rest have to come from the ideal position. However, the position of the coded target is also not the DDD chamber center, hence the added 8.585 (was 8.414). The odd numbered chambers in ring 1 in stations 2,3,4 are not visible and there is no data for their targets: we have to use ideal.
generateXYCenterFromPG.awk predicts chamber X/Y positions from the .CSV files of the excel spreadsheets, and writes the results out as C++ code fragment. NOTE THAT YOU HAVE TO SUPPLEMENT THE MISSING ENTRIES BY HAND FROM THE IDEAL GEOMETRY
Using Pivarski's tool, I modified an ideal muon geometry by subtracting 0.1rad from every chamber 1 RotX entry. The results are in the following table. The question at hand is: will simply subtracting from the existing RotX cause the chamber to look like it would in a magnetic field?
| Name | Initial RotX | TopZ-BottomZ | Correct? |
| ME+1/2 | -π | Positive | Yes |
| ME+1/3 | -π | Positive | Yes |
| ME+2/1 | -π | overlooked | ? |
| ME+2/2 | -π | Positive | Yes |
| ME+3/1 | 0 | Negative | No |
| ME+3/2 | 0 | Negative | No |
| ME+4/1 | 0 | Negative | No |
| ME-1/2 | 0 | Negative | Yes |
| ME-1/3 | 0 | Negative | Yes |
| ME-2/1 | 0 | Negative | Yes |
| ME-2/2 | 0 | Negative | Yes |
| ME-3/1 | π | Positive | No |
| ME-3/2 | π | Positive | No |
| ME-4/1 | π | Positive | No |
The answer is that the correct new RotX will be negative relative to the default for ME+1, ME+2, ME-3 and ME-4. It will be postive relative to the default for ME-1, ME-2, ME+3, and ME+4
One problem I have is predicting what the combination of disk rotation and bending is going to be. If I know a priori that I expect bending to be of some average value and want to apply it to all the chambers and then rotate the disk, the non-abelian nature of the rotation rises to bite me. However, I know a few things in advance: disk rotations are small enough that the product of two rotation angles is negligible, so I can simplify the matrices and their products; and the initial rotation about the Y axis is 0. Strictly speaking it is unmeasured, but will be taken to be 0.
Therefore the rotation of a chamber on the disk is given in the CMS standard way by Rz*Rx where
Rx is [1,0,0; 0,cos(tx),-sin(tx); 0,sin(tx),cos(tx)] and
Rz is [cos(tz),-sin(tz),0; sin(tz),cos(tz),0; 0,0,1]
and we can call this (tx,0,tz).
The rotation of the disk is given as Dz*Dy*Dx, where the rotation angles for each direction are ex, ey, and ez, or(ex,ey,ez); and where ex*ey=0 for all practical purposes. That means that the order of multiplication of these tiny rotations doesn't matter, but unfortunately they still don't commute with Rz.
A little calculation gives
Dx(ex)*Rz(tz) = Rz(tz)*Py(-ex*sin(tz))*Px(ex*cos(tz))
and
Dy(ey)*Rz(tz) = Rz(tz)*Py(ey*cos(tz))*Px(ey*sin(tz))
where of course the P matrices are tiny rotations whose multiplicative order does not matter. We can then
reorder and combine to get:
Dz*Dy*Dx*Rz*Rx = (Dz*Rz)*(Py(ey*cos(tz)-ex*sin(tz))*(Px(ey*sin(tz)+ex*cos(tz)*Rx)
so the new rotations are:
(tx+ey*sin(tz)+ex*cos(tz), ey*cos(tz)-ex*sin(tz), tz+ez)
In other notation, we have
(ε_x, ε_y, ε_z) * (θ_x, 0, θ_z) =
(θ_x + ε_y * sin(θ_z) + ε_x * cos(θ_z), ε_y * cos(θ_z)- ε_x*sin(θ_z), ε_z + θ_z)
My estimate of chamber centers from PG difers from Karoli's. The differences are not usually huge, though in Z they are of order 3mm RMS (2mm if you exclude the 12mm patch) and in X and Y of order 1mm RMS. There's a patch of 12mm shifts in Z, which seem to arise from a problem in ME-4's estimates; so this will change. Needless to say these differences far exceed photogrammetry resolution, and I suspect that the Karoli file was not simple PG-predicted centers.
Modified 16-June-2010 at 13:42
http://hep.physics.wisc.edu/~jnb/cms/16Jun2010
| Previous notes | Next notes | Main slide directory |