Jan Chrin: A Taste of CAFE Room: WBGB 021 Abstract Several Application Programming Interfaces (APIs) exist that simplifier the task of accessing EPICS-based controls data from higher level applications through Channel Access (CA), the dedicated communication protocol of EPICS. However, a number of these APIs do not necessarily reflect the recent advances in CA functionality (mainly related to multithreading and handling of lost connections) and some are tied to deprecated functions with little likelihood of being brought into compliance with the new CA standard. Applications wishing to benefit from new CA features would be better served through an in-house API that not only keeps in step with latest EPICS releases, but also presents the opportunity to provide an additional abstract layer that addresses specific requirements dictated by scientific applications. CAFE (Channel Access interFacE) is a new C++ library that provides a multifaceted interface to the latest CA functions released with EPICS version 3.14 and onwards. Functionality for both synchronous and asynchronous interactions is provided for both individual channels and groups, or collections, of channels. The basic task of writing and retrieving EPICS data is introduced through simple examples. More intricate interfaces tailored towards the needs of beam dynamics applications are progressively presented. The CAFE library is intended for use in C++ frameworks such as ROOT, and presents itself as a candidate for processing agents that, for example, capture machine physics data for storage or inter-shot analysis at the XFEL. Reference: "A Taste of CAFE", Internal Note (draft), available on request. Selected questions and discussion FLP: How can you stay in step with the evolution? JC: CAFE uses the latest CA functions; this will keep us in good stead for several years as major changes to CA functionality occur infrequently. CAFE will of course be recompiled with each EPICS release. The older C/C++ libraries (EZCA, CDEV) are tied to deprecated functions, which will continue to be included in future EPICS releases in order to maintain backward compatibility. These APIs are not however "evolving", and risk becoming obsolete. FLP: I don't understand the need for all of this! In MATLAB it's very simple to access a channel... where is the power, the benefit of this? JC: The power comes with concepts such as groups and collections, which allow you to efficiently read-out multiple channels, configured with an XML file etc. I am also addressing inter-shot analyses, which will be outside MATLAB's domain. FLP: What does dynamic mean in the context of these groups? JC: Well, a group can be created dynamically in the user's code. Since the user has control, he/she may extend the group or diminish it. However a more convenient approach is to pre-define the group in the XML configuration file; in this case the group cannot be changed at run time. However individual members may be withdrawn from any operation by setting the "rule" flag accordingly. This allows the user to adapt to changes in the operating conditions; experience has demonstrated this to be a highy desirable feature. TS: Other labs must have the same need for such a library, shouldn't this therefore be an interlab effort? JC: Most other labs are moving on to Java (but they may have to come to C for time-sensitive applications in new accelerators!). I am open for collaboration with other labs. TG: What do our controls people think of it? Are they even aware of this effort? JC: Controls group acknowledges that users will have a need to build their own CA clients/applications and even provides examples. Their responsibility however principally lies in providing the low-level libraries; they are not so interested in physics applications running in C++. TG: What effort would be required to use this at the 250 MeV injector or the PSI-XFEL? JC: None. A prototype library is available to all interested parties and is already being used within ROOT at OBLA. YK comments on the current situation in OBLA: we have added MATLAB channel access, because the diagnostics people are most familiar with it, but clearly many beamdynamics people need the equivalent for their C++ applications. It is good that we now have both! BO: MATLAB may be very fast and efficient, but you tie yourself to a company... JC: The question is not really whether you want to use MATLAB or C/C++. If you want to get something done in 10 ms, you have no choice, you have to do it in C/C++... Also keep in mind that the MATLAB interface is very basic. MB: There is also the stability issue: doing an orbit feed back in MATLAB would be crazy! BB: We did it at FLASH and suffered a lot from it! FLP: Well, what if Jan leaves? JC: What we develop is fairly generic, it should be well maintainable. MB: When you say agents, you mean distributed object, will you support CORBA? JC: So far it is standalone code. Communication would require further thought. Keep in mind that communication with CORBA takes several milliseconds and here I am addressing agents that execute events within a 10ms window. MB: But such an interface would allow communication to an online model, as we have it in the SLS... JC: That is something else, in the domain of applications. I did not want to talk about applications today (since there is a lot to say by many). MB: But that is the strength of the interface: it makes it easier to build applications in C++! BP: So you can do stuff in 10 ms, but what happens if we go to 1 kHz? JC: When we come down to 1 ms, we would enter a completely different regime, requiring a complete redesign, mainly on the hardware side with code running at lower levels FLP: Can you dump stuff in the archiver? JC: Of course, you can do anything you like. I guess the easiest thing though would be to dump data of interest into an epics channel, then you have access not just to the archiver, but to all the EPICS tools.

Stefan Binder: OBLA-500 keV and OBLA-4 MeV Simulations with OPAL Room: WBGB 021 Topics OBLA-500 keV the OPAL collimator module the OPAL pepperpot module Beamlet tail effect Cross-check of the XanaROOT emittance computation method OBLA-4MeV Focusing with the pulsed solenoid Beam focusing for different cavity power level Selected questions and discussion YK (on the OBLA-500 keV simulation and comparison with measurements): Is the thermal emmitance included? SB: It is not in the simulation (but of course in measurement). TS: In principle, one can interpret the difference between measured and simulated emittance as the thermal emittance... YK (on the simulation of the pepperpot): After passage throught the pepperpot, you have a lot less particles, don't you have to adapt the mesh size? SB: This is acutally the case. Once the pepperpot is traversed we start a new simulation with adapted grid size. YK: What is the number of particles per grid cell? It should be the same before and after! SB: Before the pepperpot, the grid is 32 x 32 x 64 (for 675000 particles), after the pepperpot we use 16 x 16 x 32 (for 3800 remaining particles). AO: What is the thickness of the pepperpot? TS: The pepperpot parameters are the ones from OBLA-500, i.e. 200 μm thickness. Note that in the software the pepperpot actually does have a finite thickness, but there are no secondary effects such as back-scattering. Electrons hitting the wall are completely absorbed. AO: Do your pepperpot simulations model an actual measurment? TS: They roughly correspond to the July 22 measurement, but the emphasis is on the pepperpot validation. We just need a realistic beam. BB: When you switch off space charge effects, is this done only after passage through the pepperpot? SB: Yes, we switch off both internal and external fields right after the pepperpot. RG: In the pepperpot simulation, what is the emittance you measure? How does it compare to the OPAL emittance? SB: Once the tails in phase space are removed (about 4% of the particles), and we deal with a more or less elliptic phase, XanaROOT reproduces quite accurately the emittance you obtain from the particle ensemble tracked by OPAL. TS: It is a fundamental limitation of the pepperpot method that it cannot be sensitive to tails, since you always hit the adjacent beamlet! YK (on OBLA 4-MeV simulations): Why do you run simulations for low power in the RF cavity? SB: These are studies to help early operation, when we are not yet sure we can reach the full power. In particular we also want to see if we can transport the beam without turning on the cavity at all.