This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern for current CERN information.
Specification c/o Ilya
Lead Use Cases
USE CASE 1: CREATE KNOB 4
2.2 USE CASE 2: SIMULATE SETTINGS 5
2.3 USE CASE 3: SEND MAD-CALCULATED CORRECTIONS TO TRIM 5
2.4 USE CASE 4: PROVIDE EXTRACTION TOOL FOR LSA MACHINE MODEL 7
2.5 USE CASE 5: ADJUSTMENT OF OFFLINE MODEL
Danger - scope creep
Possible Use Cases
Notes from meeting February 2006 with: Frank Schmidt, Werner Herr, Jorg Wenninger, Mike Lamont -
Agree that direct connection between MAD and control system not appropriate.
Concentration on easy two way transfer of data.
MAD generates TFS format - need to pull on these files and push into LSA.
Measurements from LSA at the moment coming out, mainly, in SDDS
Have available in control room set of MAD macros, scripts. Attempt to test:
Notes from LSAT meeting held on 15/2/2005.
Present: J.J. Gras, O. Br�ning, R. Lauckner, L. Normann, J-P. Koutchouk, V. Kain, A. Butterworth, L. Deniau, G. Kruk, F. Schmidt, S. Page, B. Goddard, M. Lamont, J Wenninger.
Reported by ML. Thanks to Frank Schmidt, John Jowett, Verena Kain for additional input which is incorporated below.
Frank's talk kicking off the session [pdf]. Mike's preliminary DFD below.
Essential challenge is to establish a meaningful connection between the following domains during the operation of the LHC.
- Errors: all circuits, full cycle, geometric, beam screen, eddy
- RMS/Persistent currents decay/snapback model etc.
- Transfer functions for all magnet circuits
- hysteresis behaviour (model where appropriate
1. Want to be able to tweak the model, in increments, and compare with reality. Compare what:-
[FS]... despite all our efforts the theoretical model will differ from the real machine. We should therefore attempt to have a separate database that comprises all the information that are either implied by trying to fit the model to the real world and better by actually measuring the model of the machine. Once fully understood this then should be entered to the standard data base describing the LHC.
Implicit is that a certain part of the model is naturally incorporated into the control system (tune, Q', orbit correction, Twiss [loaded offline from MAD] etc). One would NOT expect to invoke MAD on-line to perform these tasks.
2. MAD provides aperture model, misalignments handle differently. Should be tweakable.
3. Need to be able to invoke MADX in "real-time" - by this we mean from the control room and get an answer within a shift
4. provide nice complete GUI's for standard operations with given instruments/systems
5. [JJ] Documented APIs that can be used to built custom applications for special purposes. E.g. as well as having the orbit application for measuring, correcting etc., one would like to know about some Java class (or whatever) that returns an orbit measurement. That way one could do something special with it or simply correlate the information in a programmatic way with other measurements or settings. The latter type of function can save a great deal of beam time in MDs and increase the likelihood of MD data being properly analysed. It may not be enough to be able to fish it out of a vast database and then try to correlate things offline later.
6. Facilities available on all platforms
7. Off-line analysis data available from where ever. Should clearly distinguish what is planned to be done in the off-line, post MD, post run analysis phase from on-line interactions.
8. RAD [Rapid Application Development] environment to build custom made applications
9. All control system manipulations recorded.
10. Variable machine configurations
11. On-line aperture model would clearly be very useful.
Open questions, what does MAD offer? How could this be implemented other than in off-line analysis mode?
[FS] Example - single particle approach used to describe particle distributions
Want the full non-linear model available. Is this too advanced for commissioning? Need to stage any approach. It is clear that the linear part of the model should be considered first. However, the LHC, contrary to the Tevatron, Hera and RHIC will be dominated by nonlinear effects and this has to be considered early on.
FS: Non-linear model has potential to be useful from the start. In fact, the
PS booster example shows how useful this non-linear analysis can be
for a
deterministic correction of the machine. The booster people needed many months
of fiddling to get their machine running and they would have loved to have that
technique early on in the commissioning. As a result, the student Peter Ursch�tz
who did all the work (hardware, data acquisition, data analysis, simulation
studies ) proposed a better working point for this old machine based on a
simulation model that took into account measured model components.
I agree that the method has limitations and I also understand that it takes a long time till a method is finally accepted as a standard tool to operate an accelerator. However, I will follow this through to make it useful for the LHC!
Preconditions are: circulating beam with a functioning 1000 turns pick-up system best all around the machine. The possibility to kick the beam (pilot bunches for a start) at least with the tune kicker to some intermediate amplitude. It is also preferable, but not really mandatory, that some "linear" corrections have been done. In particular linear coupling which can be done with this very technique(!) and chromaticity.
FS: With my examples I wanted to demonstrate that we have means to measure many essential components of the LHC model directly from beam signal. We can detect mis-powered linear and non-linear magnetic elements around the machine. In particular we will be in the position to acquire non-linear observables which can be used to steer the accelerator.
Clearly of utmost important, need to able easily shift data between the different domains.
The general feeling was that a GUI would be only of limited use. Wide
flexibility of MAD would be very difficult to capture in a useable way. For a
non-expert, one asks what they would be wanting do anyway.
VK: it is not
necessary to have some nice GUI. This just makes it all less flexible. After a
while there'll be anyway a collection of sample jobs for all sorts of different
applications. Now thinking about the transfer lines and injection it turned
out that online matching can be useful. One could maybe think of ways to produce
MAD input directly from the fitting routines of screen shots etc.
As I mentioned above, appropriate interfaces (APIs) should be provided to access measurements and settings. Mathematica applications using J/Link (which makes all Java classes fully available in the Mathematica environment) are obviously one convenient way of building applications. I believe it is a strong candidate for a "Rapid Application Development" environment that is already familiar to many people. It would replace (or possibly co-exist with) other approaches ("scripting languages", etc.) for ad-hoc applications. I imagine that one approach to solving security and safety problems would be to deal with them in the APIs but this needs discussion.
Madtomma is an environment (set of packages) for interacting with MAD at a higher level than the MAD language allows. It has evolved a lot over the years, initially out of the LEP experience. It is easy to learn (various beginning students have used it without ever learning the MAD language) although there are still relatively few people using it in the LHC Optics team. There is an LHC-specific layer which makes it much easier and more robust to build complicated MAD applications or applications in which MAD calculation is only one aspect.
Madtomma is pretty well documented in the notebook interface, less so on the Web site. I'm gradually building up a set of tutorial examples which are available there. The LHC Optics Web pages are also built with it. I believe it could be a robust way to integrate MAD calculations into control or MD applications that use optics information.
Need for availability and usefulness of Mathematica not disputed. Appropriateness of using Mathematica operationally was questioned. (Configuration problems etc.). JJ replies that it is highly transportable particularly because configuration is now essentially identical on all computer systems.
Of course, Mathematica is also useful for the subsequent off-line analysis.
Must be done in a controlled way, otherwise anarchy.
Envision the possibility of establish complex measurements procedures using some high level scripting language (say). Clearly have to be very, very careful about what can and can't be done, security etc.
To make progress from here, it is suggested that we look in more detail at some particular Use Cases, some very simple.
