Generating and Using Transfer Plate Positions

Generating and Using Transfer Plate Positions

James N. Bellinger

7-January-2010

V1.0

Introduction

The SLM models cannot fit for transfer plate positions, and so require them as inputs. The information for this comes from several sources.

In the SLM coordinate system, “X” is along the SLM line and is approximately radial from the beamline. The SLM “Y” is along CMS Z (either plus or minus, depending on the position of the SLM) and the SLM “Z” is like “RPhi” in the CMS system.

The DCOPS Transfer Line model has essentially no handle on the CMS Z direction (SLM_Y), and so information about this has to come from other sources.

1.  Link MAB Z positions together with analog Z-sensor information and the Z-sensor models to calculate transfer plate Z-positions. This is the ideal situation. The problem is that the Z-sensor model and information do not provide reasonable results together.

2.  Predict where the transfer plates will be from photogrammetry of the disks during assembly, and use the field-on to field-off corrections to modify the Z predictions. This assumes that the Z-sensor information is correct (and the model is wrong) in the inconsistencies referred to above, and that the disk positions do not change when other disks are pushed into them during assembly.

Transfer Line fits in and of themselves do not constrain the transfer plate positions in SLM_X and SLM_Z. They require a reference.

Ideally this reference is provided by the MAB DCOPS at the outer stations, since these positions are theoretically well predicted by the Link system and thus known with respect to the tracker body. In practice we have not yet proven that this works well, though there is no evidence that it doesn’t.

Therefore we find ourselves using the photogrammetry of the outer disks, together with the photogrammetry describing the transfer plate positions on the disk, to define the ME4 station transfer plate positions. If these are correct then the rest of the transfer plate fit positions should also be correct.

Cocoa Output Processing

If you set the “report_verbose 5” and “debug_verbose 5” flags in the System Definition File (SDF) and include Guragain’s debugging changes in the code, the “report.out” file which cocoa produces will contain information about the position of all fit objects in each of the volumes in which it is contained, from the immediate mother volume all the way up to the main system volume.

This information is not in a handy form for processing, so I created an awk script to retrieve the information and rewrite it in a more convenient form. This may be found in http://www.hep.wisc.edu/~jnb/cms/tools/getframeALL.awk

The usage is

awk –f getframeALL.awk report.out | sort > new.frame

The name “new.frame” is completely arbitrary.

The output is a file that contains the mother volume referred to, the name of the volume whose position is fit, and then a series of pairs of numbers representing the X and error in X, Y and error in Y, Z and error in Z, rotation about X (degrees) and error in rotX,

rotation about Y and error in rotY, and rotation about Z and error in rotZ.

DO NOT trust the errors except for the volume immediately containing the fit volume. The correlation matrix is not modeled. The errors are in any event the results of a MINUIT fit and likely to be too small to properly represent the uncertainties.

An example might be

CMS/yep1 CMS/yep1/slm_p11/MEp1_tp1 6908.33 .25 1942.64 .89 -735 0.3 270 .04 0 .04 105 .04

The tools mentioned after this make some assumptions about the naming conventions for volumes of interest in the SDF file.

In this case since the volume of interest (MEp1_tp1) is not directly placed in the mother volume (CMS/yep1) you should ignore the errors. Nevertheless you now know that in the disk reference frame the TP1 transfer plate center should be at (6908.33, 1942.64,-735), which you can compare with the photogrammetry measurements. Of course the transfer plate center does not appear directly in photogrammetry, since it is underneath a plate underneath the SLM reference DCOPS, but you can figure out where it should be.

If you want to retrieve the transfer plate positions in their respective SLM coordinate systems you can do something like

grep ‘^CMS.ye…slm_... ‘ new.frame | grep _tp | awk ‘{print $2,$3,$5,$7}’

There is a space before the second quote mark, of course. The output will be a list with the name and the x, y, and z positions.

The obvious thing to do with such a framework file is to generate an awk script that will use the transfer plate positions from the framework file and rewrite an SDF file to use the corrected positions. This is possible using a script found in http://www.hep.wisc.edu/~jnb/cms/tools/makeNewTPAwkFile.com

The usage is

./makeNewTPAwkFile.com new.frame

It will generate a new file called new.frametimestamp.awk where the “timestamp” is a 10-digit number reflecting when the file was created, for instance 1262890809.

The resulting file can be used as (for example)

awk –f new.frame1262890809.awk PlusEndcap.sdf >PlusEndcap_Version_1.sdf

cocoa PlusEndcap_Version_1.sdf >/scratch/jnb/plusendcap_version_1.log

This of course results in a new report.out file, this time containing the fits for the Plus Endcap. You may extract the information as you please, but I use a tool called collectData.sh found at

http://www.hep.wisc.edu/~jnb/cms/tools/collectData.sh

which invokes the getframeALL.awk script mentioned above, together with several other tools:

http://www.hep.wisc.edu/~jnb/cms/tools/trimChiFile.sh

http://www.hep.wisc.edu/~jnb/cms/tools/massageChiFile.awk

http://www.hep.wisc.edu/~jnb/cms/tools/dowelx.sed

I use it by

./collectData.sh plusendcap_version_1

Where the argument passed is the log file name without the .log ending. This particular tool looks in /scratch/jnb for the log file—you will want to change this.

It creates several files, which (continuing with this naming convention) are

plusendcap_version_1.input.datafile

plusendcap_version_1.chi

plusendcap_version_1.tp.in.slm.gp

plusendcap_version_1.tp.in.slm

plusendcap_version_1.laser.data

plusendcap_version_1.frame

plusendcap_version_1.dowel.data

plusendcap_version_1.chamber

plusendcap_version_1.tp.in.slm.list

Which of these are actually going to be useful depends on the cocoa job that was just run. In the case described, where we ran on an Endcap, the .frame and the .chamber files are of interest. The .frame file is a framework file of the type described above. The .chamber file lists the chamber names, and centers and rotations in the CMS coordinate system, and the rotations in the SLM coordinate system.

Interpolation of Results

When interpolating for the ME1 chambers I found that while sometimes a simple sine wave fit described the variation well enough, several times it did not. I eyeballed the results and selected a linear interpolation when the plots didn’t look right. The fit/interpolation program I used was

http://www.hep.wisc.edu/~jnb/cms/25Oct2009/stationrings.gp

This uses the Pari/GP system. Obviously it would require fresh data, and I don’t know if you have gp available on your system. It shouldn’t be hard to rewrite in C if that proves necessary. I like Pari because it lets me do rapid prototyping without having to fiddle with matrices and pointers in C++.

The output is a list of chamber names and positions of the type being fit for. It only interpolates one kind of measurement at a time (X or Y or Z or rotation about X, etc), so this would have to be run and examined 6 times for every ring, and then the results collected to be written into a SQLite file. I have never done the latter.