1 / 13

Lattice and Model

Lattice and Model. Paul Chu. Outline. Motivation Model Server design LCLS Model Database Service layer Prototype and path forward. Motivation. Providing a universal model environment Different accelerators may use different modeling tools but some applications can be shared

zihna
Download Presentation

Lattice and Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lattice and Model Paul Chu

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

  3. Motivation • 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 P. Chu, Controls Database Collaboration, 17 Nov 2011

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

  5. Preliminary Design • 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 P. Chu, Controls Database Collaboration, 17 Nov 2011

  6. Model Run Control [1] • 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 P. Chu, Controls Database Collaboration, 17 Nov 2011

  7. Model Run Control [2] • 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 P. Chu, Controls Database Collaboration, 17 Nov 2011

  8. LCLS Machine_Model Schema [1] • 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 P. Chu, Controls Database Collaboration, 17 Nov 2011

  9. LCLS Machine_Model Schema [2] • 10 tables • 29 views mainly for individual beamlines and grouped parameters Courtesy E. Grunhaus P. Chu, Controls Database Collaboration, 17 Nov 2011

  10. LCLS Machine_ModelSize Estimate • 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 P. Chu, Controls Database Collaboration, 17 Nov 2011

  11. LCLS Machine_ModelSchema details • 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 P. Chu, Controls Database Collaboration, 17 Nov 2011

  12. Service Layer • 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 P. Chu, Controls Database Collaboration, 17 Nov 2011

  13. Prototype and Path Forward • 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 P. Chu, Controls Database Collaboration, 17 Nov 2011

More Related