Wednesday
November 1st, 14:30
CCC
conference room 874/1-011
There were no comments on the minutes of the last meeting.
Thijs asked about the relative priority of luminosity detection and installation. Helmut replied that in the 14th LHCCWG meeting it had been decided not to pursue any dedicated luminosity monitor. Mike concurred that no special effort will be needed for the 450 GeV run. A scintillator option may be followed up in the TAN & luminosity workshop, 25-26 January 2007. Helmut further commented that we will be quite happy to achieve some collisions in the first place, and to have some, however rough, luminosity estimate. In any case, beam-size information should be available regardless of the luminosity detectors
Mike presented an overview of the
LHC timing system. The RF is the LHC timing master, providing the revolution
frequency, the 40 MHz bunch frequency, as well as pre-pulses required in points
SR2 and SR8 for the LHC injection kickers. The latter are distributed via
optical fibres. A related element is the trigger,
timing and control system (TTC), which supplies each LHC experiment with an
accurate clock of less than 10 ps rms
timing jitter. The signal is sent via the same single mode optical fibres by high-power laser transmitters installed in the
PCR. The next component is the beam synchronous timing (BST), which is
primarily used by the beam instrumentation. Its architecture is based on the
TTC technology. The complete BST consists of a BST master, a TTC unit, and a
receiver interface, called the BOBR (Beam synchronous timing Receiver interface
for Beam Observation system; draft
engineering specifications by J.-J. Savioz).
Three operational BST systems and TTC networks are required, one for each LHC
ring and one for the SPS and transfer lines. The BST supplies the LHC beam
instrumentation with 40 MHz bunch synchronous triggers. A specification
on the beam synchronous timing for the LHC experiments was written up by
He now turned to the slow timing, highlighting some differences between the LHC and the fast cycling machines PS and SPS. Basic concepts of the LHC slow timing include events (asynchronous, can be subscribed to), telegrams (sent out at 1 Hz), multiplexing (playing pre-loaded settings), and the central beam and cycle manager (CBCM). Upon request the latter will provide an accurate UTC time reference. It also distributes safe beam flags and the safe beam parameters. Events will be sent on a 1-ms boundary. The maximum number of events is 7 per 1 ms. The latency of the system should be of order 100 ms. The dominant delay in operation is expected to be the operator response time.
Brennan asked whether the 100 ms is a guaranteed response. Andy explained that the CBCM will have a latency of less than 100 ms. However a longer delay could arise from the network. As an example, Mike cited that we might want to measure orbits or trim magnets in ring 1 and orbit in ring 2 at the same time, in which case the different trims should not collide.
Mike next described the nature of the “events” in more detail, and he listed important examples. In response to a question from Stephane it was noted that the power converter reference can be changed in essentially four ways: ramp function (table), trim (e.g ctrim), set (pelp) or via the real time channel. The first three are mutually exclusive. Any combination of corrections for different effects (feed-down, persistent currents etc.) will have to be done in software before loading it to the power converters. Ralph S. commented that the feedbacks use the real time channel. Jorg further commented on the possibility of performing two trims at the same time. As an example for the latter, Stephane quoted a tune shift correction, where the converter may receive a trim command from the users, plus a “soft cable” correction for b3 changes and misalignments. Mike remarked that any such “soft cabling” will have to be included in the ramp function. If a feedforward or feedback acts on the b3 spool pieces or on their feeddown, the corresponding correction could be applied via the real time input channel. In particular, the tune shift will be corrected by the real time tune feedback. Links between feedbacks may also need to be considered. Ralph S. observed that the feedback controller has to work as a slave.
Gianluigi asked about the constraint of sending no more than 7 events per ms. It was replied that this is not a serious limitation as several power converters can be combined into the same event.
Ralph S asked whether energy information is contained in the event payload. Mike replied he would address this question later.
Mike now sketched the structure of preloaded event tables, pointing out the possibility to delay certain ramps with respect to each other. Thijs asked whether some kind of priority is allocated to various events, of if, e.g., an “undo” event might arrive first, before the event it is meant to undo. Mike responded that the JAVA stack has to make sure that it receives a response first. He did not foresee any problem. Andy commented that normally functions are read back after sending.
Mike now continued the discussion of data distribution, turning to the information sent on the LHC General Machine Timing (GMT) cable at 1 Hz rate. This information includes beam type, the next injected bucket number, etc. Safe beam parameters are absolutely critical information. If they are not transmitted, the beam is dumped. Further GMT information comprises the fill number, basic period number, particle type, and UTC.
During injection, first a pre-warning is given to the injectors. SPS might also need to do some training cycles. LHC then becomes the injection master. The SPS extraction interlock will decide whether to extract or not. The timing systems will send out warning events, the LHC RF system will generate pre-pulses. The timing system does not play any role in the injection protection with the sole exception of the safe parameter distribution. Feedback and rf settings are preloaded prior to each injection. Mike showed a few more details on the role of the RF during injection.
A functional specification LHC Slow Timing System – High Level Operational Requirements is under approval.
Brennan asked whether the beam presence flag is included in the timing system. Jorg replied yes, but that it goes out for information purposes only, and that this signal is not used by the injection interlocks. Rather a dedicated much faster 1-kHz link will be provided to the injection points. The pertinent document can be found in EDMS.
Paul suggested that more general sets of clocks could be useful, e.g., clocks starting at different critical points: start of ramp, start of flat top, etc. Concerning the synchronization between machines, Gianluigi asked whether the injection between non-synchronized machines is somehow prevented at the LHC, pointing out that synchronization failures frequently occur between the PS and the SPS. Brennan commented that the TDI is a protecting device against such failures. Jorg added that the only way to avoid synchronization failures requires fast BCTs in the SPS. Paul queried how one would know that the machines are synchronized or not synchronized. Andy replied that a pick up is available for synchronizing the beam signal and the RF system. Jorg recalled a synchronization gate in LEP. Andy confirmed hat indeed a similar idea is being implemented in the LHC system. Jorg pointed out that in principle beam quality checks would also be needed in addition to timing checks. Brennan observed that no more than 0.5 s time is available on the SPS flat top for deciding on the beam transfer to the LHC.
Brennan quickly reviewed the functional architecture of the LHC beam dumping system (LBDS), gave an overview of the different cases of programmed dumps, described requirements on other systems, commented on the implementation and compiled the open questions.
The LBDS has a number of interfaces for arming, triggering, and energy tracking. Among others, a link to the injection interlock prevents injection when the LBDS is in the process of arming. In addition to the beam interlock system (BIS) also the IR6 beam loss systems and the access system can dump the beam.
The most important mode of programmed dump is called “injection & dump I” and it tentatively covers the time scale from 0 to 1000 turns. A dedicated hardware system will trigger the beam dump via the BIS. To protect the screens, the maximum number of turns has to be limited. The limit depends on the screen material and on the beam intensity. A typical limit for 1e12 protons is 30-300 turns, translating into an operation limit of 10 or 100 turns, respectively, for the two types of screens in use. The screens are protected by a combination of software and hardware interlocks, in the case of safe beam. Indeed it is preferable that this mode be limited to safe beam from SPS, which simplifies its implementation. A timing event sent briefly after the moment of the programmed dump will add redundancy to the screen protection.
The second mode, “inject & dump II”, spans the period between about 0.1 and 1000 s. In this mode, screens are not allowed. Also here the preference is to limit the mode to safe beams only, though without screens this may be less important. Another mode is the dump for an intermediate beam during injection, for which the timing system can be used. A last mode is the dump of both beams at the end of a fill.
An open question is whether always both beams should be dumped together, e.g., if the beam permit disappears for one of the two rings. According to Frank, Mike and Paul, a likely operation scenario is the dump of one beam at the end of a fill for machine study purposes with the second beam, as has been used at LEP or at the Tevatron.
Jorg commented that the option of allowing screens for any type of beam looks extremely difficult to realize. Paul remarked that indeed we do not plan to ever inject into the machine without having a safe beam already stored in the ring. So, the second option appears impossible, unless we change the rules. Also Jan later recommended that the “inject & dump I” mode with screens be limited to safe beams.
Brennan now moved on to the interlock and dump system. Functionalities required here include the triggering via the timing system. The uncertainty is a few turns. Other functions needed are an automatic reset conditional on machine mode, and a software input channel for the XPOC (External Post-Operational Check) inhibit. Jorg asked how the LBDS inhibits injection. Brennan answered that there exists a direct link.
Brennan next addressed the interplay of the beam dump with timing, rf and safe machine parameters (SMP). It is assumed that an injection prepulse is sent to IR6 10 microseconds before injection, which requires new optical fibres. Following a survey of beam screens and software interlocks, Jorg remarked that screen movement is too fast (50 ms) to be dealt with by a software interlock. Brennan replied that, in fact, the screen motion is also part of the hardware interlock.
After commenting on the sequencer and the XPOC, Brennan presented the hardware implementation for the new inject & dump mode. The communication between the beam interlock control (BIC) and the LBDS “inject & dump” crate happens through the beam permit loop. Mike asked for the length of the delay. Brennan replied that it has not yet been decided whether the injection pre-pulse 10 microseconds before injection is adequate or whether a 100-microseconds private pre-pulse would be needed. The pre-pulses are sent from LS4 to LS6 and from LS4 to LS8.
Jorg asked whether there might be problems if one wanted to dump the beam on the turn following injection. Gianluigi commented that no special synchronization is needed, but only a fixed delay between the pre-pulse and the dump trigger. Ralph S. asked whether by chance the dump could be fired even before the beam is injected. This was not thought to be possible, since, if the beam permit goes down before extraction, the beam can no longer be extracted from the SPS. In any case, this set of questions was taken to be another good argument for limiting the “inject & dump” mode to safe beam. Also, it was clarified that the turn counter input to the “inject & dump” crate simply determines after how many turns the beam is dumped.
A number of issues still need to be resolved. One of these is the delay of the pre-pulse. Brennan pointed out an advantage of the short pre-pulse lead-time. Namely the 10 microseconds minimize the dead time of the MKI during which the injection kick can no longer be stopped. Lars commented that it may, however, be safer to ask for an earlier pre-pulse in view of transmission delays. This is the approach adopted by the BI group. In conclusion, we still need a detailed analysis whether the present delay is adequate for dumping on turn 0, or whether a separate earlier pre-pulse is needed. Another question is whether the choice of the two time ranges 0 – 1000 turns (for hardware system) and 0.1-1000 s (for the timing system) is a reasonable one, the main question here concerns the value of 1000 turns. Jorg pointed out that there is a maximum number of useful turns, determined by the cycle time of the SPS.
Yet another question is the adequacy of the screen protection. Paul asked whether the injection and dump mode is a mode for the LBDS only. Brennan replied that he considers this to be a more general machine mode, which implies the possibility of using screens. Stephane took up an earlier remark by Paul and asked whether the clock always counts from injection. He suggested that we may want dump the beam a few seconds after start of ramp, for example. Mike responded that such requests can always be implemented via the ramp table.
Conditions for dumping one beam are another point further discussed. Thijs asked whether the second system arms automatically, or whether beams 1 and 2 are separate. He remarked that the conditions to dump one beam may need to be looked at with priority. Paul recalled that in LEP most MDs were done with single beams. He imagined that LHC would also have end of fill MDs like in LEP. Jorg mentioned that we can configure the BIC to separate the two beams. Paul observed that the BIC response should depend on the case. In emergency situations, both beams should be dumped, but if one beam is dumped for MD purposes the two beams should be treated in a decoupled manner. A number of questions concern the XPOC and post mortem (PM) triggering. For example, the post mortem triggers in case of beam dump may be fired for both beams, even if only one beam is dumped after a fill. Also the PM response for repeated voluntary dumping after injection may need to be reconsidered. Paul commented he could envision an LHC operation mode equivalent to the SPS scrubbing, where beam is injected and dumped on each SPS cycle. There were more questions than answers.
Mike asked who is resolving these questions. Brennan replied that some of them are being followed up at the moment by MPWG, some by Etienne, and some by himself.
Wednesday November 15th, 14:30
CCC conference room 874/1-011
Provisional agenda
Minutes of previous meeting
Matters arising
Energy tracking between sectors (Freddy Bordry)
Measurement and correction of tracking errors (Jorg)
AOB
Reported by Frank