130 likes | 141 Views
This project aims to develop a comprehensive online system for analyzing and simulating beam propagation in a machine, providing operators with essential tools for commissioning and improving the machine. The system includes a database of machine settings and diagnostics, integrated analysis software, core simulation suite, data conversion modules, scripting environment, and hardware resources.
E N D
Online Data Analysis and Simulation Sven Reiche UCLA - 09/22/04
Goals • Help operators in commissioning the machine. • Essential for semi-automated procedures (e.g. BBA). • Confirm (or reject) certain models for beam propagation. • Complete understanding of the machine, required for further modification/upgrades.
Requirements • Database of machine settings and diagnostic • Integrated analysis software (e.g. emittance measurement) • Core simulation suite (Parmela/Astra, Elegant, Genesis/Ginger) • Data conversions modules • Scripting environment • Hardware resources
Basic Set-up Machine/Experiment Change Settings Input for Simulation Diagnostic/ Measurement Derived Beam Model Comparison (Operator) Update Model Derived Measurement Complete Beam Model Start-end Simulation
Online Data Analysis • Goal to model the electron beam or to confirm an existing model. • Direct and calibrated measurements (Charge, RF Phases etc). • Programs to extract information (e.g. emittance from quad scan or tomography). • Stores information in database. • Requires eventually to automate control of the machine.
Online Simulation • Simulation, based on machine set-values and/or experimental beam model. • Reproduction of existing measurement (e.g. beam profiles at OTR screens). • Comparison with experimentally derived beam information. • Interface with machine set-value and/or experimental results.
Injector • Fast calculation of beam envelope (HOMDYN, Trace3D) or more time-consuming Particle Tracking (PARMELA, Astra). • Depends critical of the underlying model (e.g. thermal emittance) and injector settings (e.g. solenoid field, rf phase). • Weak/non-existing interface to drive laser (import profile of virtual cathode into the codes).
Linac • ELEGANT as solely choice for Linac simulation. • Execution of 3D CSR calculation (Traffic4, CSRTrack) too time consuming for online-simulation. • Because simulation depends on various machine set-values, automated interface with database is essential.
Undulator/FEL • No dynamic machine parameters (undulator lattice only). • Requires a detailed model of the electron beam. • Calculation varies from minutes (FEL amplifier model) to days (full bunch SASE simulation). • Background signal from spontaneous radiation not negligible.
Realization I • Extension of established start-end simulation by automated interface between codes and/or machine database. • Support by the code authors is essential. • Codes and code-interface programs should be scriptable or callable by a programming environment (e.g. Matlab). Simplest form of system calls (e.g. ‘system’ in C/C++ or ‘spawn’ in IDL) should be sufficient.
Realization II • Interface to database for machine set-values (dynamic parameters) and machine parameters (static parameters). • Postprocessing of simulation output is written back to database or handed over to next code (agreement on format essential). • For commissioning the postprocessor should mimic diagnostic for better comparison.
Simplification for Operation • No particle tracking for Injector • No CSR codes for Linac tracking • FEL Amplifier model only for time-dependent runs • Far-field approximation for calculation of the spontaneous background • Piecewise calculation (no single-button start-end simulation)
Conclusion • Diagnostic has to be defined so that codes can model the equivalent ‘virtual’ LCLS. • Automation between codes is straight forward if support by authors exists. • Embedded in an easy to program environment (Matlab). • Online simulation have to be fast to support the operation of the machine and not the data analysis.