Improving LHC Collimator Setup Efficiency at 3.5 TeV

Transcription

1 CERN-ATS-te MD (LHC) Improving LHC Collimator Setup Efficiency at 3.5 TeV R. W. Assmann, R. Bruce, F. Burkart, M. Cauchi, D. Deboy, L. Lari, S. Redaelli, A. Rossi, G. Valentino, D. Wollmann Keywords: LHC collimator setup Summary New software for improving collimator setup speed at 3.5 TeV was tested. The software consists of an automatic loss spike detection tool based on linear SVM, and improvements to allow for increased automation of parallel collimator setup. The tests were performed by setting up all the IR3 collimators in both beams. The results are presented and discussed in this note. 1. Introduction and Motivation The LHC collimation system is designed to clean particle losses and protect the LHC from damage due to magnet quenches, abnormal beam losses and radiation effects [1]. Beambased alignment of the LHC collimators is necessary in order to determine the beam centres and beam sizes at the collimators [2, 3]. This ensures that the correct collimator hierarchy is maintained during normal operation. Regular setups are required as the beam orbit may drift over a few months, however full collimator setups can only be performed yearly due to the amount of time required for a setup. The long time intervals between collimator setups place constraints on the minimum β* that can be achieved, and consequently the integrated luminosity reach of the LHC [4]. An automation of certain features of the alignment process described thoroughly in [5] has already reduced the time required when compared to the setup times during 2010 LHC commissioning [6]. The features consist of: Collimator jaw movement towards the beam with a user-defined step size and time interval Collimator jaw stopping when the beam losses exceed a user-defined threshold. This MD was requested to be able to test new software functionalities targeted at reducing the setup time. The functionalities consist of automatic loss spike detection and faster parallel collimator setup. The new software is integrated into the top-level LHC collimation control application as discussed in [7]. 2. Beam conditions Both beams were used, one nominal bunch per beam with nominal emittance. The machine was configured with injection optics at 3.5 TeV flat top. The variation of the beam intensity throughout the setup is shown in Figure 1.

2 Figure 1 Variation of the beam intensity throughout the collimator setup. 3. Automatic Loss Spike Pattern Recognition During all collimator setups as of this date, a collimator expert was required to visually judge if a loss pattern is a clear indication that the jaw has touched the beam by looking at the BLM signal displayed in the collimator application. This type of signal pattern is defined to be an optimal loss spike, while any other signal pattern is called a non-optimal loss spike. An automation of the setup process implies that this step must be performed automatically using a classification algorithm. 3.1 Feature Selection The first step in pattern classification involves the selection of features belonging to the BLM data which may be used to classify the type of loss spike. Based on loss spike data from previous setups, the minimum average and the height difference were identified as the ideal features for automatic loss spike recognition. Firstly, the maximum loss value is determined by taking the maximum of the 10 BLM loss values observed after the jaws have stopped moving due to the exceeded loss threshold. Although the maximum loss value is sometimes registered as soon as the threshold is exceeded, the losses often continue to increase. This effect is termed loss spike overshoot. The minimum average is then defined as the average of the least three loss points of the five loss points immediately preceding the maximum loss value. The three minimum loss points out of five are selected to ignore any previous peak which could have been generated by a previous jaw movement. h h = - 2 -

3 3.2 Pattern classification A plot of the height difference against the minimum average data obtained from the previous setup at 3.5 TeV held from 6 th to 8 th March 2011 showed that the optimal and nonoptimal loss spikes could be separated almost linearly in the feature space. The training data were labelled visually based on past experience with collimator setup of what constitutes an optimal loss spike. The linear support vector machine algorithm presented in [8] was used to be able to develop a linear classifier, and operates on a set of labelled training vectors belonging to two separate classes : =,,,,,,, R, 1,1 The hyperplane that separates the set of training vectors into two classes is given by:, + =0 where is the normal vector to the hyperplane, and the parameter determines the offset of the hyperplane from the origin along. Optimal separation of the set of vectors is possible if they can be separated without error and if the distance between the closest vector and the hyperplane is maximal. The training data is normalized to lie in the unit hypersphere [-1, 1] so that they may be fed into a linear kernel function. The normalized training data and the decision boundary are shown in Figure 2. Figure 2 rmalized feature space plot of the minimum average against the height difference. The decision classifier is determined using the linear support vector machine algorithm. A close up of the linearly separated training data with a better view of the classifier, margins and support vectors is shown in Figure

4 Figure 3 Feature space zoom showing the non-optimal and the optimal training data on the left and right side of the classifier respectively. 3.3 Application of Pattern Recognition during the MD The pattern recognition feature was enabled while setting up the IR3 collimators. It consists of window displaying: (a) the data point and the classifier in the non-normalized feature space; (b) a plot of the ± 10 BLM signal values from the stopping point versus time; (c) a red or green message depending on whether the loss spike was non-optimal or optimal respectively. Figure 4 depicts a non-optimal loss spike, where the BLM threshold was set at 5 10 Gy/s. When the BLM value of around Gy/s is reached, the collimator jaw stops moving in and pattern recognition is performed. The loss pattern is classified correctly as a non-optimal loss spike. In Figure 5 the threshold was set at 2 10 Gy/s, and although the jaws stopped moving at around Gy/s, an overshoot occurred. In this case, after the next 10 BLM data points were observed, the maximum loss value was taken to be at around This explains the large distance between the data point (circled) in the feature space and the classifier

5 Figure 4 n-optimal loss spike. The circled data point whose co-ordinates are determined from the BLM loss pattern in the bottom half of the screenshot is to the left of the linear classifier. The loss spike is correctly classified due to the proximity of the peak to the background signal

6 Figure 5 Optimal loss spike. The circled data point whose co-ordinates are determined from the BLM loss pattern in the bottom half of the screenshot is to the right of the linear classifier. The loss spike is correctly classified due to the large difference between the peak and the background signal. Out of 51 pattern recognition trials performed, there was one mis-classification. The failure in this case was due to a software bug unrelated to the pattern recognition software described in more detail in Section 4. The training data and the measured data are shown in Figure 6. Including more BLM data points in the average calculation or considering the spike width as an extra feature might result in more linearly classifiable data. Other suggestions for future work involve: Using the pattern classification response to increment the loss threshold. Changing the step size or time interval in the case of a non-optimal loss spike. Automatically declaring a collimator jaw as aligned to the beam in the case of an optimal loss spike

7 Figure 6 rmalized feature space showing the training and the test data. There was only a single mis-classification out of 51 classification trials. 4 Faster Parallel Collimator Setup 4.1 Motivation Parallel collimator setup was introduced for the 450 GeV and 3.5 TeV setups held earlier this year [5]. Although parallel setup provided some speed-up when compared to the previous linear-time setups, the drawback was that showers produced by one collimator jaw at the beam would result in crosstalk effects and cause other collimators to stop moving if the losses exceeded the threshold. For example, Figure 7 shows eight collimators moving in parallel, of which three have stopped simultaneously due to crosstalk. The user would then have to manually verify which collimator jaw is aligned to the beam by moving each stopped collimator in sequence. The step size, step time interval or BLM threshold would also have to be changed as necessary. This procedure can be automated, and the software responsible for the automation was tested during the MD

8 Figure 7 Both jaws of eight skew B1 collimators moving in parallel. The similarity of the loss spike patterns detected on each BLM and the simultaneous stopping of three collimators highlights the need for being able to automatically identify which collimator jaw is actually aligned to the beam. 4.2 Automatic Collimator Jaw Identification Technique The stopped collimators are moved in one by one depending on the options set in the window shown in Figure 8. A description of the setup options is given in Table 1. Figure 8 Parallel collimator setup options. The options are set by the operator before a parallel collimator movement, and dictate how the algorithm should behave when two or more collimators stop moving simultaneously

9 Table 1 Description of the parallel collimator setup options set before a parallel movement by the operator. Option Description Enable Automatic Parallel Enables or disables the algorithm operation. Setup Automatic Step Size (um) The step size used to move in the jaws. This is often set to 5 um so as not to create large losses with the collimator jaw that is aligned to the beam. Max. Time between first and Any collimators that stop moving during this time interval second collimator (s) are considered as having stopped due to crosstalk and are Max. no. of steps taken by each collimator unless the beam is reached before (um) moved in again sequentially. The scope of the algorithm is to find the collimator jaw which has touched the beam, so as to then be able to focus on its setup. Therefore, if a jaw has been moved by a given number of steps without the BLM threshold being exceeded, then the algorithm focuses on the next jaw. Time interval between steps (s) The time interval between steps is often increased to 3 seconds so that any loss spike overshoot exceeding the threshold can be considered before making another step. Automatically increase BLM threshold if needed Increment BLM threshold each time by (Gy/s) Max. BLM Threshold After the first beam loss spikes occur, stopping a number of collimators moving in parallel, the average of the losses after the spikes may still be above the original BLM threshold. Therefore, the user may want to instruct the algorithm to automatically increase the threshold, and this is done if the jaw cannot make a single step. If the threshold is exceeded after the second step or thereafter, the collimator jaw is declared to be aligned to the beam, and the algorithm terminates. Indicates by how much the BLM threshold should be increased if the automatic increase is enabled. The BLM threshold is increased up to a maximum value for safety reasons. A flowchart of the algorithm is shown in Figure 9. The CheckColls timer task repeatedly checks whether any collimators have stopped moving. As soon as a single collimator stops moving due to an exceeded BLM threshold, the AutomaticSequencer timer task is started to check whether any other collimators stop within a pre-defined time period (1 5 seconds). If this is the case, all the other collimators moving in parallel are stopped so that the algorithm can concentrate on only the first collimators. If both jaws of the collimator were moving in towards the beam, then the algorithm first moves in all the left jaws of each collimator in sequence, and then all the right jaws in sequence

10 Start TimerTask thread CheckColls to poll collimator status with period 1 second Move in all selected collimators in parallel Is BLM value > threshold? Start TimerTask thread AutomaticSequencer to check whether any other collimators stop moving within a time interval t. Add each stopped coll to colls[]. Re-initialize list of stopped collimators and de-select the stopped collimator Is t elapsed? Is colls.size() > 1? Stop all collimator movements i := 0, i_max := number of colls stopped, numsteps[0..i_max] = 0, issetup = false Move in colls[i] based on the setup options Is numsteps[i] == maxnumsteps? numsteps[i] += stepsize Is BLM value[i] > threshold? Is autoblmthreshold <= maxblmthreshold? issetup = true Is numsteps[i] == 0 && autoincrthreshold == true? issetup = false Move in colls[i] based on the setup options with new BLM threshold Is numsteps[i] == maxnumsteps? numsteps[i] += stepsize Is BLM value[i] > threshold? issetup = true Is numsteps[i] == 0? autoblmthreshold += IncrValue Collimator i is setup Is numsteps!= 0 && issetup == true? i := i + 1, issetup = false Is i == i_max? Stop Figure 9 Flowchart of the Algorithm to Determine the Aligned Collimator Jaw in the event of Crosstalk

11 The algorithm did not work as planned during the MD due to two bugs which could have been avoided had more time been available for testing without beam before the MD. The first bug was caused by excessive data logging by the algorithm (hundreds of lines of text were being saved to disk rather than a single line). The second bug was due to a difference in thread behaviour between the Windows development environment and the Linux deployment environment, which caused the algorithm to wait forever when the first collimator had stopped. The bugs in the software meant that no potential speed-up could be measured during the MD. The software was debugged during the technical stop and was verified to work with simulated BLM readings. In the beam recovery period after the technical stop, further satisfactory tests were performed with beam using four collimators. A sample of a typical logging output for the algorithm is shown in Figure 10, which explains the algorithm flowchart step by step: 1. Initially, the left jaws of the four collimators (TCSG.5L3.B1, TCSG.A5R3.B1, TCSG.4R3.B1 and TCSG.B5R3.B1) are moving in parallel with step size 15 µm, time interval 1 second and BLM threshold 5 10 Gy/s. 2. The TCSG.B5R3.B1 stops moving, as its BLM value of exceeds the threshold. The CheckColls timer task detects this and starts the AutomaticSequencer timer task. 3. The AutomaticSequencer timer task then counts up to Max. Time seconds, and checks if any other collimators have stopped during this period. The TCSG.4R3.B1 and the TCSG.A5R3.B1 both stop, and therefore all other collimators are stopped programmatically (the TCSG.5L3.B1). 4. The algorithm then moves in the left jaws of the TCSG.A5R3.B1, TCSG.4R3.B1 and TCSG.B5R3.B1 in sequence, starting with the TCSG.4R3.B1. However, the BLM threshold of 5 10 is below the current BLM value of , and therefore the threshold is increased in steps of 1 10 up to 7 10 Gy/s. 5. The TCSG.4R3.B1 then manages to make 2 steps of 10 µm each with a time interval of 2 seconds as defined in the options panel. However, since the maximum distance towards the beam of 20 µm has been covered, the algorithm stops the movement of the left jaw of the TCSG.4R3.B1 and moves on to the next collimator in sequence, the TCSG.A5R3.B1. 6. The BLM threshold is once again at the original 5 10 Gy/s, however there is no need to increment it as the collimator jaw manages to perform the first movement. The jaw is stopped at the second movement, as the BLM value of exceeds the threshold, and the left jaw of the TCSG.A5R3.B1 is declared to be aligned to the beam. The tests with these four collimators have shown the need for a correct selection of the setup options to obtain a reliable identification of which jaw is at the beam. In the above example, the BLM value of has only just exceeded the threshold. Therefore, in future tests the algorithm could also take into account the average BLM value before moving in the jaw again, and increase the threshold automatically if it is too close to the average

12 Figure 10 Parallel collimator setup logging of the movement of 4 collimators. Two of the collimators stop moving within 2 seconds of the first collimator. 5 IR3 Collimator Setup 5.1 Beam Offset A full setup of the IR3 collimators in both beams was performed in preparation for the combined cleaning part of the MD. The previous and the newly-established beam centres are shown in Table 2 and Table 3. Table 2 The beam centres for B1 collimators from the collimator setups of 08/03/2011 and 02/07/2011. Beam Centres (mm) Difference (mm) Collimator 08/03/ /07/2011 TCLA.6R3.B TCLA.7R3.B TCLA.A5R3.B TCLA.B5R3.B TCP.6L3.B TCSG.4R3.B TCSG.5L3.B TCSG.A5R3.B TCSG.B5R3.B

13 Table 3 The beam centres for B2 collimators from the collimator setups of 08/03/2011 and 02/07/2011. Beam Centres (mm) Difference (mm) Collimator 08/03/ /07/2011 TCLA.6L3.B TCLA.7L3.B TCLA.A5L3.B TCLA.B5L3.B TCP.6R3.B TCSG.4L3.B TCSG.5R3.B TCSG.A5L3.B TCSG.B5L3.B The results from the IR3 collimator setup show that the new centres of the collimators are less than 135 µm from the previous values, except the TCSG.5L3.B1 for which a 243 µm shift was registered. The changes in the beam centres are due to natural orbit drifts, including ground motion, temperature effects and the mis-alignment of devices such as quadrupole magnets and collimators in the tunnel [9]. Figure 11 shows a histogram of the difference in measured beam offset when compared with the previous setup. 3 Difference in IR3 Collimators Measured Beam Offset. of Collimators 2 1 Beam 1 Beam Difference in Measured Beam Offset (mm) 5.2 Collimator Setup Time Figure 11 Difference in IR3 collimators measured beam offset. The collimator setup time is defined as the time used for setup divided by the number of collimators that have been setup. The collimator setup process involves determining the beam centre and beam size at each collimator. In order to determine the beam size at the collimators,

14 a reference collimator needs to be aligned to the beam before and after the setup of each collimator i. The beam centre can then be determined from the left and right jaw positions of the collimator i. The reference collimator is taken to be the primary (TCP) collimator in the same plane (horizontal, vertical or skew) as the collimator i. The setup process is explained in greater detail in [3]. The beam 2 collimators listed in Table 3 were setup while debugging of the program was ongoing with the beam 1 collimators listed in Table 2, and then a switch was performed. However, since the parallel setup algorithm was still not fully debugged, no speed-up could be measured. Additionally, no beam dumps due to collimator setup were recorded, confirming the safety of the semi-automatic alignment software. Table 4 shows the times for each setup. Table 4 The setup times for the IR3 B1 and B2 collimators. Setup Type Start Time Stop Time. of collimators Time per collimator (mins) IR3 B IR3 B * *In this case the reference primary was not setup before and after each collimator in order to save time for the combined cleaning tests. Therefore, only the beam centres could be determined. 6. Outlook The results from the pattern recognition tests have been encouraging, and more MD time to collect test and training data would be necessary in order to start using this technique as part of a fully automated collimator setup process. The testing of the algorithm to identify which collimator has touched the beam during parallel setup has highlighted the need for a simulator to model the formation and behaviour of beam losses during collimator setup. Reinforcement rather than supervised learning techniques will also be investigated to see if these can also be used in fully automatic collimator setup. References [1] R. W. Assmann et al. Requirements for the LHC Collimation System. In Proceedings of EPAC 2002, Paris, France, [2] R. W. Assmann. Collimation for the LHC High Intensity Beams. In Proceedings of HB2010, Morschach, Switzerland. [3] D. Wollmann et al. First Cleaning with LHC Collimators. In Proceedings of IPAC 2010, Kyoto, Japan, [4] R. Bruce, R. W. Assmann, W. Herr. Calculation Method for Safe Beta* in the LHC. Submitted for publication in IPAC 2011, San Sebastian, Spain, [5] G. Valentino, R. W. Assmann, S. Redaelli, N. Sammut, D. Wollmann. Semi-Automatic Beam-Based Alignment Algorithm for the LHC Collimation System. Submitted for publication in IPAC 2011, San Sebastian, Spain,

15 [6] G. Valentino et al. Comparison of LHC Collimator Setups with Manual and Semi- Automatic Collimator Alignment. Submitted for publication in IPAC 2011, San Sebastian, Spain, [7] S. Redaelli, R. W. Assmann, M. Jonker, M. Lamont. Application Software for the LHC Collimators and Movable Elements. CERN EDMS document no. LHC-TCT-ES-0001 (2007). [8] C. Cortes and V. Vapnik. Support-Vector Networks. In Machine Learning, Vol. 20,. 3, pp , [9] R. J. Steinhagen. LHC Stability and Feedback Control Orbit and Energy. CERN-THESIS