Notes from LHC tune software meeting Monday, January 22, 2007. Present: Dean Still, Jerry Annala, Dennis Nicklaus, Jim Patrick (FNAL) Mike Lamont, Ralph Steinhagen (CERN) Dave McGinnis visual webex only from USPAS Agenda was Jim Patrick going over our understanding of the system and what needs to be done, asking questions along the way. System Overview: There are three sets of stripline pickups in the IR4 straight: - For tune measurement via excitation ("Tune-FFT"). FFTs correlated with beam excitation are read and analyzed to give the tune. - For tune feedback ("Tune-PLL"). A phase locked loop system provides continuous measurement of the tune. This is passed by a dedicated link to a feedback system that controls power supplies to stabilize the tune. This is particularly important up the ramp to compensate for the snapback. - A spare system in case of failure of one of the above, and possibly for use in development. - Each set has horizontal and vertical pickups for each of the two beams. The general architecture consists of - pickups - BBQ front-end electronics - DAB board which digitizes BBQ data and computes FFT. For PLL case, the tune and other parameters are also computed. - All electronics and DAB boards are identical for all systems. There are several ways to excite the beam: - Excitation through a transverse damper or a stripline pickup. This is controlled via the DAB board. A switch on a mezannine card directs the excitation signal to either the damper or stripline. As excitation and acquisition are controlled by the same board, synchronization of the two is straightforwardly done. - Dedicated tune kicker. This is not controlled by the DAB board but there is supposed to be some mechanism to ensure data is synchronized with the kick. Via the timing system. Full details still to be worked out. DAB board buffering: - The DAB board is only double buffered. One buffer is in use for acquisition/FFT computation while the other is available for readout by the FESA front-end. It is currently not envisioned that the front-end will provide additional buffering. The goal will be to deliver spectra to the application at 25 Hz, the same rate BPM data is sent to the orbit feedback. Controls Middleware (CMW) monitoring requests can only do at most a few Hz. Therefore it is proposed to use a "real-time channel" protocol developed for the orbit system. The application will make a subscription request to the front-end via CMW. The front-end will send the data directly to the application via UDP. It is believed the protocol should be able to handle this rate. The maximum FFT acquisition rate the DAB board can do is 50 Hz of 2048 turn acquisitions. Some concern was expressed about the refresh rate capability of the display, there are reports that sometimes in the orbit viewer for the SPS after a while the display lags the data by many seconds. The JDataviewer has the capability of "batching" added points so a plot does not have to be completely redrawn for every point. The refresh capabilities of the JDataviewer will be investigated further. Required capabilities of GUI program: - Configure DAB board for acquisition and excitation parameters. While many things may be manipulated, as this is a basic operator application very few parameters need to be exposed. Probably just the number of turns and excitation method and perhaps strength. It is believed the parameters configured by the operator should not have to change for ramp/squeeze/coast. Whenever the DAB is reset, it comes up in the proper default configuration. - Start/stop data acquisition, display, excitation. - Display numerical results for tune, and excitation status. - Plot tune vs time - 2-D contour (waterfall) plot of FFT spectra vs time - Single FFT spectra with peaks found by TSpectrum - Tune displayed on resonance line plot - 3D FFT vs time - Beam Transfer functions. These may be obtained from the PLL system by correlating data with the excitation frequency at which it was acquired. While in principle they may be obtained from chirp excitation, it is believed this will happen too fast for a good measurement. - Save and restore files. Allow operator to acquire data for some time period and save file in SDDS format. Program should be able read and display these files. Ralph suggests it be possible to save additional processing (TSpectrum output etc.) and not just raw FFT data. - Automatic capture during the ramp and squeeze is desirable. Maybe I missed it, but it didn't seem clear how this would be done. - Ralph pointed out the coupling could be measured by chirp'ing one plane and reading the other. While the PLL system is supposed to measure the coupling on the DAB board, this may be a useful alternative/fallback. Post Mortem issues: - Data to be output from the system in response to a post-mortem event has been specified. As the results wind up in SDDS files, it could (should?) be investigated as to whether the application can read and display these files. Schedule issues: - The FESA front-end is supposed to be developed by the end of March by beam instrumentation people. However it is expected it will mostly be used by BI people for hardware testing. - A front-end is being developed for the SPS, the plan is to replace the old BOSC system there with a system like this. A good pre-LHC test would be to make an application acquire data from this system at 25 Hz and display it in a fixed-display for SPS machine development. - The front-end for the LHC should be very similar to that for the SPS. It is believed that hardware installation at IR4 (pickups, cabling etc.) is well advanced. The system should be available some time in the summer(?) The basic functionality will be needed early in beam commissioning. The goal to have the PLL system commissioned within 1 month of beam. Comments on demo program: - A demo program to study the capabilities of JDataviewer was created by Jim Patrick and put into the CERN code management system. This included a contour plot of FFT spectra vs time, and the capability to display a single FFT selected from that plot. The ROOT TSpectrum class Ralph mentioned at the last meeting was ported to Java, and deconvolved spectra and peaks found by that were plotted on top of the raw data. For illustration data from the 1.7 GHz Schottky at Fermilab were used. - The JDataviewer has many useful features for this type of plot including color contour plot, ability to add (one) cursor to a plot, zoom capability, ability to synchronize the X-axis of multiple plots, ability to draw arbitrary lines. The contour plot currently does not have a scale legend, however this is on Greg Kruk's list of things to do. Also it does not have a true 3-D plot view. - Ralph said he generally liked it and offered the following suggestions: - Superimpose peaks found by TSpectrum on the contour plot - Add ability to change between linear and log scale - Normalize secondary peaks to largest peak. - Display tune vs time with missing acquisitions obvious - Would like a true 3-D plot. A demo program was made using the package developed some years ago by Joy Kyriakapoulos here that uses Java 3D. This didn't look that great and was slow for the data size. An attempt will be made to make it available for others to run, but it does require Java 3-D to be installed on the PC where it runs. Ralph mentioned Java bindings to OpenGL, this and other possibilities will be investigated. - Ralph would like to use the port of TSpectrum in other applications. Mike says to contact Greg Kruk about where to put it. - Ralph has .WAV files of data acquired using a BBQ front-end at RHIC. This may be found at /afs/cern.ch/user/r/rstein/public/Wave5_whole_RHIC_cycle.wav These would be more representative than the Tevatron Schottky files. However it is a raw file that is 228MB, so will take some time to digest. Also on Marek Gasior's 3D-BBQ home page: http://mgasior.web.cern.ch/mgasior/pro/3D-BBQ/3D-BBQ.html are .WAV files from the SPS and PS.