1. This material is based upon work supported by the U.S. Department of Energy Office of Science under Cooperative Agreement DE-SC0000661. Michigan State University designs and establishes FRIB as a DOE Office of Science National User Facility in support of the mission of the Office of Nuclear Physics. Paul Chu Lattice and Model

2.  Motivation  Model Server design  LCLS Model Database  Service layer  Prototype and path forward Outline P. Chu, Controls Database Collaboration, 17 Nov 2011, Slide 2

3.  Providing a universal model environment Different accelerators may use different modeling tools but some applications can be shared Universal API useful for future application development  Connection to control systems  Centralized model computation Reducing application complexity Model results shared  Client apps same for both online tuning and offline analysis  Simple, clean API for all model needs Motivation P. Chu, Controls Database Collaboration, 17 Nov 2011, Slide 3

4. Overview P. Chu, Controls Database Collaboration, 17 Nov 2011, Slide 4

5.  Using XAL data structure XAL accelerator hierarchy suitable for holding model data Set/get model data to/from XAL (data access API) Advantage: it is in Java, i.e. supporting Matlab, Jython  Using Java or scripting language to generate non-XAL model input files Prototyped for IMPACT (in Python)  Using scripting language to parse non-XAL model output files  Using scripting language for model run control Start/stop/abort a model run Scheduling on cluster Monitoring run status by checking a meta file Saving data to file system, then relational database  Data storage similar to LCLS MACHINE_MODEL schema Preliminary Design P. Chu, Controls Database Collaboration, 17 Nov 2011, Slide 5

6.  Initialization Establish CA and DB connection Construct Accelerator object  For live machine model, programmatically generate the input file  Schedule/run model, monitor progress  Collect model run result  Insert model run result into XAL data structure  Update model service data In-memory DB for quick access Store persistent data in RDB  Client apps access model data via API Model Run Control [1] P. Chu, Controls Database Collaboration, 17 Nov 2011, Slide 6

7.  Adapters between XAL and non-XAL models for both input and output  Arrange/schedule model runs  Monitoring run status for offline tracking  Hook to service provider Model Run Control [2] P. Chu, Controls Database Collaboration, 17 Nov 2011, Slide 7

8.  Model run on standalone app, on-demand based  3 databases – production, QA and production-for-external-use  Model data entered in Oracle DB with JDBC PL/SQL procedural calls for data validation, integrity check Failover protection  Model data indexed for better performance LCLS Machine_Model Schema [1] P. Chu, Controls Database Collaboration, 17 Nov 2011, Slide 8

9. LCLS Machine_Model Schema [2] P. Chu, Controls Database Collaboration, 17 Nov 2011, Slide 9  10 tables Table Name# of Cols# of IndexesSizeTablespace DEVICE_TYPES7364KMACHINE_MODEL ELEMENT_MODELS6141664MMACHINE_MODEL GOLD72128KMACHINE_MODEL HARDWARE_SETTINGS6264KMACHINE_MODEL INITIAL_CONDITIONS6264KMACHINE_MODEL MODEL_DEVICES104304MMACHINE_MODEL MODEL_LINES6264KMACHINE_MODEL MODEL_MODES7364KMACHINE_MODEL RUNS145448KMACHINE_MODEL XML_DOCS131128KMACHINE_MODEL  29 views mainly for individual beamlines and grouped parameters Courtesy E. Grunhaus

10.  29 views mainly for individual beamlines 5 beamlines  ~2500 elements for the LCLS “FULL MACHINE” line  Total data after 3 years ~2 GB, ~10 runs per day while operating  Support DESIGN and EXTANT models LCLS Machine_Model Size Estimate P. Chu, Controls Database Collaboration, 17 Nov 2011, Slide 10

11.  DEVICE_TYPES: link to the component tables  ELEMENT_MODELS: actual model data  GOLD: keep track of GOLD model history  HARDWARE_SETTINGS: link to SCORE (data correlation)  INITIAL_CONDITIONS: can be used for different initial beam conditions. Not in use for now.  MODEL_DEVICES: machine settings for model run input  MODEL_LINES: beamlines  MODEL_MODES: can distinguish, say, different MPS or running modes  RUNS: different model runs, e.g. date, design/extant, comments etc.  XML_DOCS: can save model data as XML files LCLS Machine_Model Schema details P. Chu, Controls Database Collaboration, 17 Nov 2011, Slide 11

12.  Communication protocol – TBD XML-RPC, JSON-RPC for simple data types PVAccess?  How to package and transport model data Mainly simple data such as getBetaX(), getEmitX(), getEnergy() Maybe getAllBetaFor(a_beamline_section), getAllBetaFor(all_magnets)  Broadcasting/on-demand pulling/Subscription to a service Service Layer P. Chu, Controls Database Collaboration, 17 Nov 2011, Slide 12

13.  XAL data structure and access API is basically ready Maybe need convenient wrapper API  XML-RPC based service prototyped for data communication Is PVAccess/PVData ready for complex data structure?  Lattice DB schema can base on LCLS MACHINE_MODEL  Need IRMIS data access API for Lattice Prototype and Path Forward P. Chu, Controls Database Collaboration, 17 Nov 2011, Slide 13