CERN Accelerating science

BEAM LOSS MONITORS

• Threshold tables etc (discussion at MP commissioning meeting jan 08)
• Installation drawings

4000 BLMs: 3600 Ionization chambers and 400 SEM for higher loss intensities

First cut requirements spec - mid 2007

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

Preliminary list of Requirements follow below.

Regarding your other questions, the 16 Historical properties (Historical1, Historical2,...) relate to the 16 channels connected to this card.  Inside each of these properties you have a a 2D array of 20 by 12.  The 20 refers to a historical sliding window (ie.  each 1000ms a new reading is taken from the channels and inserted in position 20 while the existing ones are shifted left by 1).  In other words, you should discard the values[0..18][] and only look at values[19][].  The 2nd dimension relates to the integration times for the BLM data:

In the operational design, the 20 historical values won't be there (there will just be 12 values per channel) - They are there now to make up for the lack of the fixed display.  In the operational interface, I expect the sliding window to be at the client (your) level if needed, which will greatly reduce the overhead of sending the data (by a factor of 20!).  In fact, the 'historicalX' properties won't be there at all and you will access the single 'Acquisition' property (containing 16 arrays of 12 values).

If it were me, I'd organise the the display to show only 'problem' channels (where the values were approaching a warning state), and only show 1 of the integration times (eg 0.04ms).  Otherwise you're going to struggle to fit > 40'000 values on a graph :)  On the other hand, it's could be useful to see many integration times for a selection of channels to see the loss evolution when there's problems.

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.

Threshold management

1,500,000 values
250 families

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 ..