THaRaster.h THaBPM.h THaUnRasteredBeam.h HallA_LinkDef.h THaBeamDet.h THaRasteredBeam.h THaRaster.C THaUnRasteredBeam.C THaBPM.C THaRasteredBeam.C THaBeamDet.CExamples (can be found in $ANALYZER/examples/BPM):
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)
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.datOf 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:
I.) [xy_detmap] 1 2 1 23 0 3 1881 -1 0 0 0 0 0 0Where xy is the name of the beamline 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 moduleAsk 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.
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.First line gives:
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)2nd - 4th line: z position of 1st and 2nd beamline 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 dont 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
B1 B2 A11 A22 A12 A21means
x_HCS = B1 + A11 * x_raster + A12 * y_raster y_HCS = B2 + A21 * x_raster + A22 * y_rasterThere is a script: get_raster_coeff.C as an example to extract this trafo. This transformation changes at least from run to run, if the beam was tuned during a run even more frequent. Currently I do not support the latter case with the root 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)
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. Dont bother to much if you dont 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 To obtain this transformation you need an analyzed bulls eye scan. The script get_bpm_calib.C will then extract those numbers for both BPM's
// 1. MCC hast 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
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 root analyzer)
Put those results into a table, together with the run number of the corresponding coda run. This will look like:
$ 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 ....With 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.)
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.