% !TeX spellcheck = en_GB
%
%
% v 2.3  Feb 2019   Volker RW Schaa
%		# changes in the collaboration therefore updated file "jacow-collaboration.tex"
%		# all References with DOIs have their period/full stop before the DOI (after pp. or year)
%		# in the author/affiliation block all ZIP codes in square brackets removed as it was not %         understood as optional parameter and ZIP codes had bin put in brackets
%       # References to the current IPAC are changed to "IPAC'19, Melbourne, Australia"
%       # font for ‘url’ style changed to ‘newtxtt’ as it is easier to distinguish "O" and "0"
%
\documentclass[a4paper,
               %boxit,        % check whether paper is inside correct margins
               %titlepage,    % separate title page
               %refpage       % separate references
               %biblatex,     % biblatex is used
               keeplastbox,   % flushend option: not to un-indent last line in References
               %nospread,     % flushend option: do not fill with whitespace to balance columns
               %hyphens,      % allow \url to hyphenate at "-" (hyphens)
               %xetex,        % use XeLaTeX to process the file
               %luatex,       % use LuaLaTeX to process the file
               ]{jacow}
%
% ONLY FOR \footnote in table/tabular
%
\usepackage{pdfpages,multirow,ragged2e} %
%
% CHANGE SEQUENCE OF GRAPHICS EXTENSION TO BE EMBEDDED
% ----------------------------------------------------
% test for XeTeX where the sequence is by default eps-> pdf, jpg, png, pdf, ...
%    and the JACoW template provides JACpic2v3.eps and JACpic2v3.jpg which
%    might generates errors, therefore PNG and JPG first
%
\makeatletter%
	\ifboolexpr{bool{xetex}}
	 {\renewcommand{\Gin@extensions}{.pdf,%
	                    .png,.jpg,.bmp,.pict,.tif,.psd,.mac,.sga,.tga,.gif,%
	                    .eps,.ps,%
	                    }}{}
\makeatother

% CHECK FOR XeTeX/LuaTeX BEFORE DEFINING AN INPUT ENCODING
% --------------------------------------------------------
%   utf8  is default for XeTeX/LuaTeX
%   utf8  in LaTeX only realises a small portion of codes
%
\ifboolexpr{bool{xetex} or bool{luatex}} % test for XeTeX/LuaTeX
 {}                                      % input encoding is utf8 by default
 {\usepackage[utf8]{inputenc}}           % switch to utf8

\usepackage[USenglish]{babel}

%
% if BibLaTeX is used
%
\ifboolexpr{bool{jacowbiblatex}}%
 {%
  \addbibresource{jacow-test.bib}
  \addbibresource{biblatex-examples.bib}
 }{}
\listfiles

%%
%%   Lengths for the spaces in the title
%%   \setlength\titleblockstartskip{..}  %before title, default 3pt
%%   \setlength\titleblockmiddleskip{..} %between title + author, default 1em
%%   \setlength\titleblockendskip{..}    %afterauthor, default 1em

\begin{document}

\title{Summary of Session 2: Systems Overview}

\author{T. Argyropoulos\thanks{theodoros.argyropoulos@cern.ch}, T. Levens\thanks{tom.levens@cern.ch}}
	
\maketitle

\section{Introduction}
    
The second session of the workshop gave an overview of the performance and evolution of individual systems during Run 2. The systems covered in this session were the general technical services, cryogenics, controls, RF system, injection systems, beam instrumentation, and emittance measurements. The systems overview was continued in Session 3.

The topics addressed include the availability and downtime generated by each system, the lessons learnt from recommissioning the system after LS1, the main evolution of the system and issues encountered during Run 2, the main limitations encountered during Run 2, and the changes foreseen and how they will impact performance during Run 3.

% ----------------------------------------------------
\section{General Technical Services}

\textbf{L. Serio} introduced CERN's technical infrastructure systems and the Technical Infrastructure Operations Committee (TIOC). He then gave an overview of the performance of the electrical network (EL) and cooling and ventilation (CV) during Run 2 and highlighted the improvement in availability that has been made during the run. He then covered the major events that occurred during Run 2 and the consolidation planned during LS2. The outlook for Run 3 was presented, highlighting the risks as a number of consolidation projects have been postponed due to budget and manpower restrictions. Finally he presented some new tools based on machine learning to forecast future availability.

\subsection{Discussion}

\textbf{R. Steerenberg} asked for clarification about the colour coding on slide 23 where the postponed EN-EL consolidation was presented. \textbf{L. Serio} replied that the items highlighted in red are the most critical to address if resources were made available.

With regards to the weasel events, \textbf{F. Bordry} asked what has been done to avoid this happening again. \textbf{L. Serio} replied that the protection of the most transformer terminals has been completed, with some still to be done during LS2. Nevertheless, other systems where there is the possibility of animals getting into contact with live terminals should also be investigated.

\textbf{D. Nisbet} asked if there was anything in particular that caused ten times more faults for CV in 2016 compare to other years. \textbf{L. Serio} replied that there were a large number of flooding events in that year, but generally these had a low impact on the machine.

With regards to consolidation, \textbf{M. Lamont} pointed out that the availability of both EL and CV is very good and is evidence that these groups are doing an excellent job with limited resources. Although they cannot do everything that they want to do, a lot is already being done but he acknowledges that challenges remain. \textbf{L. Serio} pointed out that there are certain critical items not covered by the present consolidation programmes. For example, the insulation failures seen on HVA transformers may continue in the coming years. For CV, the ageing of the water circuits remains a concern. \textbf{M. Lamont} reemphasised that the message is that we have limited resources and cannot do everything. \textbf{L. Serio} agreed, but warns that that there could still be a single event causing a large amount of downtime.

\textbf{G. Arduini} asked how the level of redundancy we have compares to industry standards. \textbf{L. Serio} answered that it depends on the type of industry you compare to. He pointed out that we do not have the same level of redundancy compared to industries with a continuous process system. The redundancy that we have does not always guarantee the ability to continue operation but only to reduce the downtime. The figures presented should be comparable to industries with a similar level of redundancy.

As a final point \textbf{L. Serio} reiterated that while the level of maintenance is generally not bad, there are still systems of which a failure could cause a large amount of downtime. The amount of investment in maintenance and consolidation of the technical services should be compared to other parts of the organisation.

% ----------------------------------------------------
\section{Cryogenics}

\textbf{G. Ferlin} presented the cryogenic performance and availability for Run 2. He highlighted the major maintenance and consolidations along with the software upgrades and data analysis planned for LS2. Finally he presented the expected cooling power limitations for Run 3.

\subsection{Discussion}

Based on the experience over the previous years, \textbf{R. Steerenberg} asked if the rhythm of a technical stop every eleven weeks is still required by cryogenics. \textbf{G. Ferlin} reminded that over the previous two years these technical stops were used to unclog filters. The problem of leaks is expected to be solved during LS2 and so this maintenance should no longer be necessary. But at least two thirds of technical stops have been used to repair a major problem. While having three regular stops may not be necessary, it will still be necessary to have stops during the year. \textbf{J. Wenninger} asked if they could be made shorter. \textbf{G. Ferlin} replied that if there is not a major problem then they could be made shorter. The limitation remains the time required to empty and refill the RF and triplets. \textbf{F. Bordry} commented that if we could push to have only two technical stops it would be a good thing.

\textbf{R. Steerenberg} asked if something was changed that could lead to the slight increase in the unavailability due to electromagnetic sensitivity and instrumentation in 2018. \textbf{G. Ferlin} replied that there was no specific cause identified. A complete inspection of all electrical cabinets should be performed during LS2 as this was not possible during the run.

\textbf{M. Pojer} commented that, although there were a number of cryogenic faults during 2018, these only lead to a 2\% loss of availability. As planned technical stops cost 5-10\%, it might be beneficial to change the strategy and keep running until a cryogenic fault occurs. Avoiding the overhead of the scheduled technical stops may lead to an overall improvement in availability. \textbf{G. Ferlin} reminded that a large number of minor problems are resolved during the technical stops. It will still be necessary to have a few long stops per year and in this scenario they would just not be at fixed times. \textbf{C. Schwick} remarked that any reduction in the number of technical stops should be discussed with the experiments. \textbf{P. Collier} reminded that there are other users in the machine that require technical stops and that having planned stops, even if there are fewer, is better for everyone. 

\textbf{P. Collier} also commented that quenches causes by the users are included in the cryogenics downtime figures. This makes the numbers look worse and, in reality, the availability of the cryogenics system is incredibly good. He suggests that these should be split in the statistics to better reflect the actual availability of the cryogenic system.

% ----------------------------------------------------
\section{Controls and the Accelerator Fault Tracking Tool}

\textbf{C. Roderick} highlighted the performance and evolution of the controls system during Run 2, including the introduction of the Smooth Upgrades Working Group. He then moved on to the major changes expected during LS2: the WorldFIP renovation, the end of life of many old technologies, the introduction of NXCALS and the future GUI strategy. Finally he presented the recommissioning strategy and outlook for Run 3. Moving onto the Accelerator Fault Tracking Tool (AFT) he presented the history of the tool, what it has brought and some ideas of where it should go next.

\subsection{Discussion}

\textbf{J. Uythoven} commented that the idea of making major controls changes between fills sounds scary. These sort of changes must be discussed with MPP and may require an intensity ramp up.

\textbf{D. Valuch} asked if a concrete statement can be made on what kind of GUIs will be supported in the future. \textbf{V. Baggiolini} responded that Oracle has indicated that Java clients will no longer be supported. This external factor, together with the rise of Python, leads CO to now look to Python GUIs as the main successor of Java. They also want to explore web technologies, but the baseline for the medium term is Python. However no immediate change is necessary and in the short term the answer is still to use Java Swing.

\textbf{V. Kain} wondered if we will have enough flexibility to operate the machines with the tools that will be available after LS2 and asks if there anything that can be done to make the timing system more flexible and to handle the increasing complexity of the SIS. \textbf{C. Roderick} replied that this is an interesting question that should be discussed in more detail.

% ----------------------------------------------------
\section{The RF System}

\textbf{K. Turaj} gave an overview of the availability and general performance of the RF system, with a summary of the different categories of faults seen during 2018. She then moved on to the developments that have been made to the software and diagnostics tools and highlighted the scripts that have been developed to aid with the recommissioning of the system. Next, she presented the system limitations seen during Run 2 and the anticipated limitations for Run 3. Finally she presented the maintenance work being done during LS2 and the preparation and testing of the spare cryo-modules.

\subsection{Discussion}

\textbf{A. Siemko} asked if we have a spare module available considering the unexpected heat-load measurements. \textbf{K. Turaj} replied that, yes, the spare module is available. The heat-load is thought to be due to a higher helium level compared to the machine. Analysis of the data suggests that the static head-load is correct and a second test is being done to cross check the result. It should be noted that these results are from flow meter measurements which are not done in the machine.

With regards to availability, \textbf{R. Steerenberg} noted that on two occasions there was downtime related to software and asks if something can be gained using a test bed. \textbf{K. Turaj} replied that we can gain a lot, but it is hard to include the behaviour of the beam in a test stand and this remains a limitation. A test stand containing exactly what is installed in the machine is planned to enable testing before it is implemented in the machine.

% ----------------------------------------------------
\section{Injection Systems}

\textbf{F.~Velotti} presented an overview of the LHC injection system, summarising the hardware and performance evolution during Run 2.  At first, the high availability of the LHC injection system over the years, with values above 99.2~\%, was shown, emphasising on the main faults recorded during the 2018 Run, related to the MKI. The significant evolution of the MKI and TDI and their achieved performance were then presented. The talk was later focused on the SPS-to-LHC transfer lines. A detailed analysis on the steering process was shown, identifying the main sources causing shot-to-shot variations and long term drifts. Analysis of the transverse losses at injection was presented afterwards and based on that, an empirical model was developed, which was used to predict the expected losses in Run 3. Finally, the foreseen improvements and changes during LS2 as well as the commissioning plan of Run 3 were discussed. \textbf{F.~Velotti} concluded that towards Run 3 and the goal of 1.8~p/b in 1.8~$\mu$m, no limitation from the injection devices is expected.

\subsection{Discussion}

\textbf{P.~Collier} asked if it is possible to include the bumpers in the steering algorithm at the SPS to re-correct the position and the angle at the extraction point and thus to correct the variations in the transfer lines. \textbf{F.~Velotti} replied that this is one of the proposals, to have the full model including all the extraction regions the bumpers and the extraction septa as well. \textbf{J.~Wenninger} commented that using the bumpers in addition, does not change anything and that the only way to gain is to correct before extraction so that the beam comes into the line already on the good trajectory. \textbf{V.~Kain} added that the problem is that we cannot measure the beam position well enough with the BPMs, and that with these large bumps there is an uncertainty of several millimetres. She mentioned however, that with the new orbit system, it might be different and perhaps something can be done about this.

% ----------------------------------------------------
\section{Beam Instrumentation}

\textbf{M.~Krupa} presented a general overview of the beam instrumentation during Run 2. He discussed the improvements applied during this time, the operational experience gained, the achieved performance and the future developments of the major BI systems, namely the BPMs (orbit, interlock, DOROS), the BLMs (main, diamond), the  BCTs (DC, fast), the orbit and tune feedbacks, the BBQ and finally the Schottky, instability  and other special diagnostics. Later, the global availability and the occurred faults of the BI systems in 2018 were shown and compared with the previous years of Run 2. \textbf{M.~Krupa} stressed the decreased faults and the increased availability of the BI systems over the years. He emphasised on the fact that 2018 was the best year for the BLMs, resulting from the actions taken during LS1 and that the fault tracking of “Controls”, introduced in 2018, together with AFT could be used to further improve the systems. He concluded that all major BI systems are ready for Run 3, mentioning that a dedicated BI commissioning time is going to be needed. 

\subsection{Discussion}

\textbf{T.~Lefevre} commented that one possible way to improve the Schottky measurement is by making the pick-up movable in order to be able to come closer to the beam at top energy to increase the sensitivity. However, he added that this cannot be done during LS2 since it requires a completely new system. \textbf{R.~Steerenberg} pointed out that the Schottky, although is operational, it still requires a lot of expert knowledge in order to be used as a diagnostic tool, asking if something can be done on that matter. \textbf{M.~Krupa} replied that they are working on it in BI. A detailed analysis of the data acquired during the run is taking place, and the extraction of the useful information in an automatised way for OP is being considered.

\textbf{D.~Wollmann} asked what more is needed for the diamond BLMs, from the BI side, to become available for the non-expert users. \textbf{M.~Krupa} replied that the system will become fully operational after LS2. \textbf{B.~Salvachua} commented that after summer 2018, data from diamond BLMs was coming in a more standard way. In addition, a GUI application was implemented in the CCC providing the possibility to extract the data from NXCALS or look directly at the losses. This will be finalised during LS2. 

\textbf{G.~Arduini} asked if the DOROS BPMs can acquire turn-by-turn data. \textbf{M.~Krupa} replied that this can be provided. \textbf{G.~Arduini} asked if there is the possibility by clicking a button to save a set of data of a selection of devices. \textbf{M.~Krupa} replied that in principle all the data are stored. \textbf{D.~Valuch} commented that the LHC instability monitor which was built exactly for this purpose and that different instrument connected to it which are saved after the instability is triggered. \textbf{T.~Levens} commented that at the moment there no software infrastructure to collect these data. There is a possibility to do this in NXCALS or to have a system similar to post-mortem to collect snapshots of data. \textbf{V.~Kain} mentioned that this exists only at the LHC injection with the IQC, pointing out that something like this has to be extended.


% ----------------------------------------------------
\section{Emittance Measurements}

\textbf{G.~Trad} presented a summary of the emittance measurements during Run 2. He gave a general overview of the main devices that are used to measure the bunch sizes, namely the Wire-Scanners (WS), the Synchrotron Radiation Monitors (BSRT, Interferometer and Coronagraph), the Beam Gas Vertex (BGV) detector and the Quadrupolar BPMs. The overall hardware and performance evolution of these devices during Run 2 was provided together with the main challenges and issues encountered. The plans for future improvements and actions to be taken during LS2 were also discussed.  Finally, \textbf{G.~Trad} commented on the errors in the calculated emittances from the measured bunch sizes, if the dispersion is not properly taken into account as well as the discrepancy of the measured emittances with respect to those obtained from the luminosity measurements.

\subsection{Discussion}

\textbf{S.~Radaelli} asked if the Coronaghraph will be available only at HL-LHC and not during Run 3. \textbf{G.~Trad} replied  that the system is installed only on B2 and its use excludes both the use of BSRT and the Abort-Gap Monitor, raising also issues of machine protection. However, the system is already installed which means that after some setting-up it can be used in machine studies. For HL-LHC, another point of light extraction at D4 is foreseen dedicated to the Coronagraph. 

\textbf{S.~Radaelli} commented that it is important to use the quadrupolar moment already during the commissioning, because measurements of the beam sizes is important for the collimators. \textbf{G.~Trad} replied that dedicated studies took place in the last MD block. \textbf{T.~Lefevre} commented that all the cross calibrations shown here in comparison with the WS, were done with DOROS running on  normal BPMs. The plot in page 29, shows curves of emittance calculations reconstructed during the ramp by the 12 different BPMs, located around the ring and not collimator BPMs. Assuming that the actual emittance does not change drastically during the ramp, the discrepancies indicate that there is a wrong knowledge of the optics. \textbf{G.~Trad} commented that there is a known 10~\% beta-beating during the ramp which is seen by all the instruments. \textbf{T.~Lefevre} added that there is a lot of data acquired during Run 2 that need to be processed. The problem with the collimators is that when they are moving, the beam conditions are changed which makes even the relative measurements difficult. At flat bottom or flat top relative measurements are possible since the collimators are not moving. 

\textbf{B.~Salvant} asked if there is also a possibility of an optical damage when the intensity is going to be increased to 1.8$\times10^{11}$~p/b. \textbf{G.~Trad} replied this will be taken care by filters. 

\textbf{G.~Ardruini} asked if in slide 6 the difference between the WS in B1V is understood. \textbf{G.~Trad} replied that these plots show the difference in terms of scale between the two potentiometers. These are calibrated with external interferometers which  for space issues are installed only on the spare WS. 

\textbf{G.~Adruini} asked if it is planned for the BGV to be used in profile mode. \textbf{G.~Trad} replied that the BGV colleagues are investigating the addition of a third detector plane that will allow to process the data in a way that it become less depending on the multi-scattering from the exit window, making the use of the vertexing mode possible. For the moment the vertexing resolution is very bad. 

\textbf{G.~Adruini} asked if it is possible to vary the speed of the WS during the calibration run, in particular for points with lower beta. \textbf{G.~Trad} replied that this is not an option for the time being. 

\end{document}
