Hall A Analyzer

h1. Analyzing BPMs

h2. List of files

Source code:

<pre>

THaRaster.h

THaBPM.h

THaUnRasteredBeam.h

HallA_LinkDef.h

THaBeamDet.h

THaRasteredBeam.h

THaRaster.C

THaUnRasteredBeam.C

THaBPM.C

THaRasteredBeam.C

THaBeamDet.C

</pre>

Examples (can be found in @$ANALYZER/examples/BPM@):

<pre>

beam_db.dat             database for B.Reitz's beam apparatus/detectors

                        (one has to create appropriate soft links to this file)

check_bpm_calib.C       to verify the BPM calibration constants are okay (bulls eye scan needed)

get_bpm_calib.C         to extract BPM calibration constants (bulls eye scan needed)

get_bpm_pedestals.C     to extract BPM pedestals (special CODA run needed)

get_rast_const.C        to extract transformation coefficients between raster currents and position 

harp_results.txt        results of the harp scan analysis (needed to run 

                        bpm_calib scripts)

</pre>

h2. Details about the database file

The database elements for all beam line detectors can be stored in principle in one file, however the analyzer expects different database files for the different detectors. One way to cope with this feature is to put everything in a single file (@beam_db.dat@) and create soft links for all detectors, like in the following example: 

<pre>

ln -s beam_db.dat db_rb.Raster.dat 

ln -s beam_db.dat db_urb.BPMA.dat 

ln -s beam_db.dat db_urb.BPMB.dat 

</pre>

Of course you can also have three files, which only need to have the necessary blocks.

The database file is an ASCII file, which is read in line-by-line. There are several blocks containing relevant information in a fixed format. Between the blocks one can add comments as wanted, but not in the blocks itself.

A block starts with a line containing a keyword in square brackets (no leading spaces or other leading characters are allowed).

The following blocks are known and needed:

<pre>

I.)

[xy_detmap]

               1      2          1            23          0 3       1881

              -1       0         0            0           0 0       0

</pre>

Where xy is the name of the beam line detector as defined in the beam apparatus (currently I am using Raster, BPMA and BPMB, caution it is case sensitive). Next line(s) are the detector map lines in ESPACE style:

* first detector channel

* ROC number

* Crate number

* Slot number

* first channel on digitizing module

* last channel on digitizing module

* type of digitizing module

Ask Bob Michaels or the experimenters to get these numbers. They are also hidden in the detector map which is inserted in the CODA file.

Lines are read in, until the first detector channel is negative. 

<pre>

II.)

[Raster]

-23.0 18.3 18.3   0 0 1633   1643

-7.345

-2.214

0.0

0. 0. 1. 1. 0. 0.

0. 0. 1. 1. 0. 0.

0. 0. 1. 1. 0. 0.

</pre>

First line gives: 

<pre>

z-position of the raster magnets in meters (not used) [Arun Saha, Surveys]

x-frequency of the raster magnets in kHz (currently not used) 

y-frequency of the raster magnets in kHz (currently not used)

            [Bob Michaels, Bill Gunning should know what was used. 

             18.3/18.3 is typical for circular raster,

             22.4/18.3 or 18.3/22.4 is typical for a traditional square raster] 

2* pedestals for magnet current in x (y) (currently not used, since accounted for below)

2* pedestals for derivative of magnet current in x (y)   (currently not used, to 

            get those, one has to plot  histograms of raster.rawslope1(2), the pedestal

            is defined as the point right in the middle of the two peaks)

</pre>

2nd - 4th line: z position of 1st and 2nd beam line detector and the target. (Those are the planes at which the x and y position of the beam is calculated at) One should use the surveyed position of the two BPMs and 0. as nominal interaction point. Although the provided tools do not correct for the fact, that BPMs and harps are not exactly at the same z-position. Therefore don't be surprised if you see the position of the two harps instead, it doesn't make a difference within the resolution of these devices.

5th - 7th line: linear transformation from raster currents (in ADC channels) to the x/y position in the three previously defined planes (in meters).

A line like 

<pre>

B1 B2 A11 A22 A12 A21

</pre>

means 

<pre>

x_HCS = B1 + A11 * x_raster + A12 * y_raster

y_HCS = B2 + A21 * x_raster + A22 * y_raster

</pre>

There is a script: @get_raster_coeff.C@ as an example to extract this transformation. This transformation changes at least from run to run, or even more frequently if the beam was tuned during a run. Currently I do not support the latter case with the analyzer. This will be added, as soon as the general database support is a little more stable. (Espace already supports time dependent trafos even within a run)

<pre>

III.)

[BPMA]

-7.345 0.01887  1.1 1.1

0 0 0 0

-1.0269  1.0300  1.0846 0.95947  -4.09371E-04  3.91314E-04

(Of course there is a similar block for BPMB)

First line: z-position of the device (in meters)

            calibration constant (historically set to 0.01887 to produce reasonable 

            big numbers in the rotated coordinate system. One can change this number, but has 

            to repeat the calibration of the other numbers afterwards)

            phase difference between x(y) position determined by device and real position

            (currently not used)

Second line: pedestals for the four antennas. Don't bother to much if you don't know them.

            The bulls eye scan can mostly compensate wrong values here. If you change them,

            you have to repeat the calibration of the numbers in the last line.

	    You need a special bpm_pedestal run to measure them (see comments in 

            get_bpm_pedestals.C e.g., this script would also analyze such a run )

Third line: Linear transformation from BPM coordinates to HCS coordinates, in the above 

            example:

            x_HCS [meter] = -1.0269 rot1 + 1.0300  rot2 - 4.09371E-04

            y_HCS [meter] =  1.0846 rot1 + 0.95947 rot2 + 3.91314E-04

</pre>

To obtain this transformation you need an analyzed bulls eye scan. The script @get_bpm_calib.C@ will then extract those numbers for both BPMs.

h2. How to use all this stuff

# get a template for the beamline database file

# make sure that the detector map entries are correct

# make sure that the z-positions of the BPMs/target are up to date in the database

# during the experiment: perform a bpm_pedestal run: 

<pre>

//   1.   MCC has to follow the following procedure

//   1.1    Open BPM window "BPM Diagnostics - SEE"

//   1.2    From there pull down the "Expert Screens" and open "Gain Control"

//   1.3    For IOCSE10, use the pull down window and change from "auto gain"

//          to "forced gain". Then change the Forced Gain values x and y to zero.

//   2.   CODA has to run in pedestal mode

</pre>

# run @get_bpm_pedestals.C@ in the analyzer (you might have to modify some details) it should print out the new pedestals at the end. Load the database into an editor and change them (2nd line of the @[BPMx]@ blocks) 

# Next step is a so called bulls eye scan. Therefore you need unrastered beam. 

#* Ask MCC to steer the beam to the nominal center of the target (caution you should not do this with a target requiring rastered beam, use carbon, BeO, optics, or in the worst case empty instead). Wait until beam is stable and perform a harp scan and a CODA run right next to each other. Ask MCC then to steer the beam to positions around the nominal center, covering at least the area the raster will cover, and repeat harp and CODA runs.

#* Analyze the harp scans, making sure you use the latest survey results to get the corrected beam position. (To analyze harp runs follow the instructions on the web. They are not in the scope of the analyzer.)

Put those results into a table, together with the run number of the corresponding CODA run. This will look like: 

<pre>

$ more harp_results.txt 

1154 62  -1747.0  131.0  1665.00  339.9   517.00  101.0  1012.00  315.5 1493.90   730.23  -.44  -.13

1155 64  -1614.0  124.0  2829.00  343.6   693.00   96.0  2908.00  329.9 1688.46  2942.09  -.45   .02

1156 65  -3256.0  124.0  2889.00  346.5 -1422.00   98.0  2993.00  331.2 -630.64  3037.88  -.36   .02

....

</pre>

where the columns are: CODA RunID, Harp RunID, positions (and sigmas) at 1H04a (~BPMA), 1H04b (~BPMB) and the extrapolated position and angle at the pivot point (z=0) in [um]

#* The script @get_bpm_calib.C@ can now be used. It reads in this table, analyzes the CODA runs and finally prints out the coefficients, which one has to copy into the database (3rd line of the @[BPMx]@ section.) 

# You can check if this worked out by running @check_bpm_calib.C@. It again analyzes the runs of the bulls-eye scan and plots the reconstructed positions versus the results of the harp analysis.

# If your experiment takes data with unrastered beam you are done now. Simply use this database and the @THaUnRasteredBeam@ Apparatus to obtain the beam position and direction. It will give those two parameters for each event, and will automatically take care of drifts and or (slow) changes of them. !!! This will not work with rastered beam, even worse by doing so you would use a beam position which is off, and the offset might even depend on other kinematical variables, or is at least not randomly. 

# If your experiment takes data with rastered beam:

#* The BPMs are unfortunately too slow to measure the position of the beam at the time when the electron actually hits the target, they have a shift in the order of micro-seconds. The Raster magnets have a much smaller phase difference and can be used directly, however the relation between the current in the raster and actual beam deflection and beam position depends on beam energy and on beam tuning. Therefore this calibration has to be redone for all data individually. In principle it can change even within one CODA run if MCC had to do retuning while the experiment did not stop data taking. This latter case is currently not supported, but will be added in a later version of the root analyzer. However it is recommended to get a new beam_db.dat file for each run, where the @[Raster]@ block is adjusted accordingly. This already implies, that one has to go through the data in a two step analysis. 

#* Use a generic @beam_db.dat@ file and run a script similar to @get_rast_consts.C@. It uses the @THaUnRasteredBeam@ apparatus to get the centroid and the size of the raster using the BPMs, and the @THaRasteredBeam@ apparatus to get the centroid and width of the current in the raster for one CODA run. Out of those values it calculates the diagonal matrix elements and offsets for the raster to position transformation, which are printed and need to be put into the database file for that run. (If someone automates this procedure, let me know ;) This procedure has a sign ambiguity for both the horizontal and the vertical width. This sign depends on cabling and ADCs used, and can therefore change between experiments. Only checking the data can reveal if things are done properly. E.g. looking at the correlation between @rb.x@ and @L/R.gold.y@ will show if the sign for the horizontal calibration is correct. The vertical sign can be checked by looking at a sharp peak in an energy spectrum (emiss, omega), before and after applying extended target corrections. If the sign is correct, the width of the peak should get smaller after the corrections. 

#* Now you can replay the CODA run again, this time using the @THaRasteredBeam@ Apparatus (with the individual database file) to get the phase correct event-by-event beam position and using all Apparatus (like HRS ...) and physics packages needed for a complete analysis. 

#* For online analysis the procedure seems rather complicated. Probably the best way is to use the @THaIdealBeam@ apparatus instead, which always puts the beam position to its nominal value, and use the more sophisticated analysis for offline purposes later on. 

Bodo Reitz

Last modified Jul 28, 2004