1 / 14

Online Modeling of the Fermilab Accelerators

Online Modeling of the Fermilab Accelerators. Elliott McCrory Leo Michelotti Jean-Francois Ostiguy Beam Physics Department Fermilab. Outline. I. Beam Physics Computation Environment II. Physics Analysis Client Applications Online Database Online Models Open Access Models (Redirection)

tarmon
Download Presentation

Online Modeling of the Fermilab Accelerators

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. Online Modeling of the Fermilab Accelerators Elliott McCrory Leo Michelotti Jean-Francois Ostiguy Beam Physics Department Fermilab

  2. Outline I. Beam Physics Computation Environment II. Physics Analysis Client Applications • Online Database • Online Models • Open Access Models (Redirection) • Standalone Applications III. Limitations IV. Possible Directions V. Summary

  3. I. Beam Physics Computation Environment • MXYZPTLK Library • Lie Algebra and Automatic Differentiation • Valid to any desired order • Beamline Library • Lattice construction, hierarchy and analysis classes • Object-Oriented C++ • Modular and distinct • One person can learn a small piece of the system and improve it.

  4. Front End Controls Console (1) Server (2) FMI Computation Server 1 OAM MXYZPTLK & Beamline Classes FMI Computation Server 2 Front End TCP/IP ... OLM RR Computation Server 2 Front End Normal Applications (4) . . . (3) Relational Database Model Tables Online Model Architecture

  5. II A. Online Database of Physics Parameters • Commercial Sybase Database Server • We generate static database tables for • Lattice Elements • names, positions, alignment • Lattice Values • orbit, twiss, R-matrix, covariance matrix • C-callable functions to access these tables • For Controls application programmers

  6. Static Database Example sql> select * from lattice_twiss where lattice_name = "MI_20" 2> go lattice_name slot_number alphax betaxpsix dispx dprimex alphay betay psiy dispy dprimey -------------------- ----------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- MI_20 0 0.935708 15.306615 0.000000 -0.035001 0.003318 -2.046558 43.169907 0.000000 0.000000 0.000000 MI_20 1 0.609946 11.197358 0.204496 -0.026179 0.003318 -2.366082 54.901296 0.054637 0.000000 0.000000 MI_20 2 0.572599 10.836919 0.232169 -0.025168 0.003318 -2.402715 56.354825 0.060117 0.000000 0.000000 MI_20 3 0.538435 10.527148 0.258276 -0.024243 0.003318 -2.436224 57.703984 0.065006 0.000000 0.000000 MI_20 4 0.538435 10.527148 0.258276 -0.024243 0.003318 -2.436224 57.703984 0.065006 0.000000 0.000000 […]

  7. II B. Online Models • Beam physics computations for existing machines at Fermilab • The user may change beam line devices and have the model predict the effect • Controls Applications on VMS • The Client • Computation on Unix • The Server • Solaris/SPARC & Linux/Pentium

  8. OLM: BPM’s & Model of 8GeV Line

  9. II C. Open Access Models • Console Redirection • Virtual Machine for testing normal Controls Applications • Proof-of-principle for FMI & RR • Problems remain • Development is tedious: the exact behavior of all front ends must be duplicated.

  10. II D. General-Purpose Fitting & Tuning • Offline Program • Variables & constraints defined dynamically by user • Fit can be dynamically monitored (& stopped) • See Ostiguy’s Talk in 30 minutes • Recycler Trombone

  11. III. Limitations • Legacy environment • VAX/VMS; C subroutine calls • Changes dominated by: • Compile time • Complexity of the Controls API • Model-based redirection is too low • Requires specific knowledge of the hardware • Changes in hardware (common) must be transferred to the simulation

  12. IV. Possible Directions • Build model ideas into controls database • E.g., all beam line classes in control system have hooks to return the design twiss values at that point. • Create an abstraction layer that is satisfactory to Controls and to Models • For example: • Abstract class BeamPosition • All real BPMs support this abstraction • Most functionality of any BPM is in this abstraction • Could be an “interface” • Abstract class Orbit, uses BeamPosition

  13. V. Summary • Beam Physics Computation Classes • Extremely accurate, arbitrary-order beam physics calculations • Integrated into Fermilab Control System • Static Database lookup via C • On-Line Models (OLM) • Console redirection proof-of-principle (OAM) • Standalone Applications • Need Abstraction layer in control system

More Related