1. Model Server for Physics Applications Paul Chu SLAC National Accelerator Laboratory October 15, 2010

2. Model Server, P. Chu P. 2 SLAC (LCLS) BNL (NSLS-II) LBL Others? Collaboration

3. Model Server, P. Chu P. 3 Current Model Server –LCLS XAL based envelope tracking – not covering all physics needs. –Data saved in Oracle DBs Multiple model runs available. –AIDA as communication interface. –Performance Presently, a new model needs 1-2 minutes before available to clients. –Robustness Model GUI app being a heavy applications. No state control during lengthy model update period. Motivation

4. Model Server, P. Chu P. 4 Proper physics –LCLS XAL model not good for low energy end, undulator and beyond. Sometimes, need multi-particle tracking. Flexible – a universal model host platform. –Even for data from Model Independent Analysis (MIA). Better performance –Running/updating continuously as a service. Updating data ~ a few seconds for online model. –Accessing data with better technology/API, e.g. EPICS v.4 pvAccess. Start-to-end simulation included –Separate run-control program for external code. –Beam dynamics codes can be semi online. Service-oriented architecture –Easy for any client applications to use. –Centralized control. Multiple model runs concurrently What new Model server can provide?

5. Model Server, P. Chu P. 5 Run control –Support user-defined parameters. API should provide parameter “scan”. –Support saved machine setup, i.e. replay. Easy to program a complicated experiment with SOA design –Support scripting, e.g. Python, Matlab. Additional Features

6. Model Server, P. Chu P. 6 Possible Model Clients Linac Energy Management (LEM) Feedback Matching Lattice Diagnostics Online Simulator/Virtual Accelerator …

7. Model Server, P. Chu P. 7 Service-Oriented Architecture  Model Service in the big picture.  Many other commonly used modules should be services as well.

8. Model Server, P. Chu P. 8 Architecture Design  Input data  Some from other services.  Synchronizing with live machine.  Adapter for each supported model code.  Model run control script.  Model output data format converter.  Model data service engine.  Any client applications.

9. Model Server, P. Chu P. 9 XAL and its data structure. –XAL hierarchy is suitable for the common data format but needs more attributes. EPICS v.4 pvAccess. S2E prototype (IMPACT-T run control). Numerous existing applications using model data. What We Have

10. Model Server, P. Chu P. 10 Prototype Run-Control Originally developed 3 years ago. Adding new features. Support IMPACT-T. Written in Python/Jython/Java –Python/Jython for system call to external particle tracking programs. –Java for GUI. File I/O based –Run parameters in XML file. –stdin, stdout, stderr to log file. –Keep updating a “heartbeat” file while tracking is running. –Meta data written into a temp file. –Each run is in a separate self-contained folder. Features –Support DESIGN, user-defined and LIVE (in progress). –Monitoring (by checking various files), controlling runs.

11. Model Server, P. Chu P. 11 Prototype Run-Control (cont.) Project in SourceForge repo  http://sourceforge.net/projects/s2e/

12. Model Server, P. Chu P. 12 1.Finish live machine model support. 2.Define common but narrow APIs first, e.g. set***(), get***(). 3.Use EPICS v4 for Virtual Accelerator. –Performance and reliability test. 4.Post model data to model service. –Using EPICS v4 pvAccess 5.Port models to the model server. –XAL –IMPACT-T –Elegant –Model independent (MIA) data, i.e. Machine Server What to do

13. Model Server, P. Chu P. 13 6.Improve IMPACT-T code for LCLS. 7.Write client applications. –Set up AP Toolbox for Model Server. 8.Use RDB instead of file I/O. 9.Model Host platform –Parallel cluster study. –Particle distribution generator. –Initial condition editor. What to do (cont.)

14. Model Server, P. Chu P. 14 Model Server/Service –It is closer to reality than it sounds. –Good progress on run-control program. –There is a lot of work ahead. Summary