CERN Accelerating science

BEAM LOSS MONITORS

Discussion with Bernd Dehning 9th November 2004  including  BLMs at HERA

Preliminary list of Requirements follow below.

Beam Loss Monitors - requirements

• ~4000 monitors
• Plus the possibility of movable BLMs
• 2 different acquisition system, different monitors for 2 beams
• Essentially passive. Potentially huge amount of data.
• Secure adjustment of dump thresholds - not the operators, please not the operators.
• Various Integration times at front-end - potentially pushing up 44,000 values at 1 Hz. Data reduction at source.
• Quench level varies with energy, different observation windows and thresholds - Threshold table. Critical.
• Possibility to filter out zero or near zero before logging to avoid logging unnecessary values.

Timing

Crates have BOBR timing card - connected to BST.

Post Mortem

• Buffer last 100 - to 1000 turns
• Average rates on timescales of a few seconds and 10 minutes before a beam dump
• Thresholds
• Interface to machine protection

Data pushed up on the receipt of a post-mortem event. What post event analysis needs to be done?

Fixed Display

• Normalized loss rates
• Thresholds
• History, moving average
• Coincidence signals from several nearby quadrupoles
• Rates: RT or slower
• Single/ multipole monitor zoom

Logging

What, how, how often and in what format?

• Measured and calculated loss rates at 1 Hz [different integration periods].  From 40 microsecond to 60 seconds - 40 microseconds gives the maximum seen in any given 40 microseconds in a second.
• Threshold table - see BD above, threshold values, maximums and other misc data. Total 28 k per minute [check!]
• Analysis: cross-correlation against everything
• Times stamping, correlation of measurements from different monitors, different sets of monitors.
• Mode dependent logging frequency

Comments from Ronny:

• 1. LHC Logging is not intended as an on-line real-time monitoring system in order to serve live Fixed Displays.
• 2. Chucks of buffered data must be sent, currently the limitation is 1MB XML file
• 3. The frequency of the data file sending is ideally in the order of every 10 minutes. This limit has been stretched for shot-by-shot logging to approximately every 20 seconds.
• 4. Channel names are predefined and expected to respect LHC naming conventions
• 5. Data is expected to be time stamped with UTC
• 6. Data filtering and reduction would be highly appreciated
• 7. Importing of HERA BLM data in the logging database would be an interesting test for the data vizualisation point of view

Real time acquisition

Getting hold of the contents of the post-mortem buffer i.e. turn by turn data, even when there isn't a PM event.

Experiments' BLMs

Haul them in along with the rest.

Integration into optimization procedures

• Collimator optimisation  Loss discrimination
• Synchronized acquisition

Other Issues

• Warnings? Alarms?
• Malfunctioning, disable monitor.
• Operational checks before beam.
• Who fills the threshold tables? Who sets the warning levels, dump levels and such.

Lars..
1) The only reason for adding the thresholds to the BLM electronics would be if we have:

A) Connection to the LHC injection BICs with inhibit in case losses > thresholds
B) Alarms in case the losses > thresholds

Could you please comment on A) and B)

We will have to check with Bernd what he intends to do about the thresholds as a function of
energy as I'm not convinced the transmission via the timing system will be ready and tested then !!

2) The single-pass transfer-line BLMs (BLMI) include monitors around the MSI and MKI and for those I can create alarms and we can connect the system to the BIC (TI8 or LHC injection or both) .. Jorg is thinking about this ..