computing for accelerator physics
TRANSCRIPT
Computing for accelerator physics
Ilya Agapov, 7/12/09, DESY Computing Seminar
Contents
Overview of accelerators and computing requirements Electromagnetic field and thermal calculations Accelerator optics and beam dynamics codes Collective effects Energy deposition calculations and machinedetector interface Start to end accelerator simulations Control systems, online accelerator modeling and diagnostics
Areas where computing plays a role
I will cover beam physicsand some controls issues
Basic accelerator types and components
Linear Accelerators (injectors, linear collider,FEL, spallation neutron sources) Cyclotrons Synchrotrons (light sources, storage rings) Advanced accelerator concepts (plasmawakefield)
Linear accelerators
100keV test injector at PSI Accelerating cavity (from ACCEL) Dipole (from APS Argonne)
Injectorts for synchrotrons Neutron sources Linear colliders (SLC, ILC, CLIC) Acceleratordriven nuclear power Ion therapy
DESY XFEL Layout
Synchrotrons HEP and nuclear physics Circular colliders Light sources
7
Plasmawakefield acceleration
From CERN Courier June 2007
Use wakes created in plasma by intense electron or laser beams Accelerating tp ~1GeV over ~ 3 cm (would take ~1030m with RF) Challenges: energy spread, beam emittance,maintaining accelerating gradient, module staging Proof of concept SLAC, LBNL
Computing in the project lifecycle
EM field calculations
LHC main quad, ROXIE (from Russenschuk) Cavity electric field from www.gdfidl.de
Heat transfer, mechanical stress Stress and heat transfer calculations for dumps, targets, cryostats ANSYS AUTODYN (now part of ANSYS)
CST particle studio
Collimator wakefiels (www.cst.com) Particle gun
vectorfields.comOPERA2D, OPERA3DMagnetostatics, thermal, quench,...
Commercial codes Pros: CADlevel graphics, powerful mesh generation and solvers Contras: expensive, hard to extend
bunch
moving mesh
Electromagnetic
Code for
Handling
Of
Harmful
Collective
Effects
Wakefield code ECHO (TU Darmstadt / DESY)
Zagorodnov I, Weiland T., TE/TM Field Solver for Particle Beam Simulations without Numerical Cherenkov Radiation// Physical Review – STAB,8, 2005.Zagorodnov I., Indirect Methods for Wake Potential Integration // Physical Review STAB, 9, 2006.
Slides I. Zagorodnov DESY)S
in 2.5D stand alone application
in 3D only solver, modelling and meshing in CST Microwave Studio
Preprocessorin Matlab
Model and mesh in CST
MicrowaveStudio
ECHO 3DSolver
Postprocessorin Matlab
It allows for accurate calcu lat ions on conven t ional PC with on ly 1 p rocessor. To be p aralleliz ed …
Wakefield code ECHO (TU Darmstadt / DESY)
Beam optics
Accelerator dimensions given by: maximum accelerating E field (linear) maximum bending magnet strength (circular) Tasks of beam optics – steer the beam to the experimental station meeting the constraints:
✔ geometrical layout steering with dipole magnets – e.g. Desy to Schenefeld✔ fit in the aperture (focusing)✔ provide necessary beam sizes at experimental stations (focusing)✔ correct chromatic effects (focusing depending on energy)✔ in circular accelerators – in addition provide stability
Common approach (strong focusing) – build accelerators from blocks similar to light optics e.g. dipole magnet – bend, quadrupole – focus/defocus, sextupole correct aberrations, RF cavity accelerate
Linear opticsStart with equations of singleparticle motion in the EM fieldsIn a coordinate system going with a reference onaxis particle all building blocks can be represented by parametrized coordinate transformationswhere x,x', y, y' – particle coordinates and trajectory angles with respect to reference orbit
Each transform depends on few parameters (usually just one).For basic optics linear approximation is sufficient. The transform is a matrix
Taken from A. Streun,lectures at ETH
Linear opticsA typical parametrization – through socalled twiss parameters
A beam transport system (e.g. beam parameters) easily given by matrix multiplication.Writing a program to SIMULATE linear beam optics is straightforward and can be done in a matter of days (fortran) or hours (matlab, mathematica, python, root etc.). Almost every computerinclined accelerator specialist has probably done it.
Computeraided design: Too many free parameters. Still designed by humans from analytical principlesstarting from simple building blocks (FODO cell; final doublet/triplet) Only tuning (matching) of optics: find exact magnet settings to fit the beam size at IP
Further issues, e.g.: Powering constraints Cost issues (tunnel length minimization, required current minimization)
Attempts at multiobjective genetic optimization have been made
x s=s cos s
Complications Some magnet types can be more complicated (e.g. LHC magnet with spool pieces; fringes etc.) Sextupoles and higher order multipoles should be included (compute chromatic functions) Collective effects – at least simple calculations useful (Intrabeam scattering) Aperture and layout information (to go to a more engineering design) Input formats (portability between codes still bad but improving)
tracking required for:
Steering algorithms for linacs (PLACET) For strongly nonlinear fields (extraction through a quad pocket) no sensible parametrization exists Longtern stability in storage rings – small perturbations play role – symplectic integrators (nonlinear dynamics) Presence of synchrotron radiation, gas scattering
Steering (PLACET code, D.Schulte, A.Latina et al.)Slides by A.Latina (FNAL)
Longterm stability, dynamic aperture
Poincare section for linear (left) and nonlinear maps (right) Determining stability for largeamplitude particles requires longterm tracking Symplectic integrators to avoid large error accumulation Long term stability under influence of small random perturbations (RF noise, scattering)requires sofisticated computeintensive techniques (e.g. 6D FokkerPlanck equation) Spin dynamics in storage rings
Codes: COSY, PTC,…Julia Set
MADX Widely used beam optics code www.cern.ch/mad LHC standard; has builtin high precision integrators (PTC), treats hight order multipoles Comprehensive set of beam physics processes Matching of beam parameters Spits out optics tables, can be plotted with external tools or builtin ps driver call file="../LHC-cell.seq";
kqf = 0.010988503297557 ;kqd = -0.011623337240602 ;
Beam, particle = proton, sequence=lhccell, energy = 450.0, NPART=1.05E11, sige= 4.5e-4 ;
use,period=lhccell;
select, flag=twiss, clear;select, flag=twiss,column=s,name,betx,bety,mux,muy;twiss, sequence=lhccell,file='twiss-output';
match,sequence=lhccell;constraint,sequence=lhccell,range=#e,mux=0.28,muy=0.31;vary,name=kqf,step=1.0e-6;vary,name=kqd,step=1.0e-6;lmdif,calls=500,tolerance=1.e-21;endmatch;
value, kqf;value, kqd;
Collective effects a computational physics research area similar to plasma simulations
Wakes and space charge (gdfidl, echo)
Wakefield acceleration (PIC OSIRIS)
Beambeam effects in colliders (GUINEAPIG)
Electron clouds (codes: HEADTAIL, ECLOUD, FAKTOR2)
Energy deposition and machinedetector interface
Was not a problem in the early years With more beam energy/intensity and superconducting magnets particle losses due to scattering, collimation system performance etc. become more critical Similar type of calculations as with HEP detectors (showers), but need to link it with beam dynamics in the machine Interfacing MonteCarlo radiation transport (FLUKA, GEANT4, MCNP, MARS) toaccelerator tracking Examples: STRUCT/MARS at FNAL; FLUKA/SIXTRACK for LHC; BDSIM (standalone GEANT4 based tracking for ILC and ATF2)
29
BDSIM Complicated geometries are possible (e.g. extraction with electron and photon dump lines, bottom left). Detailed or simplified equipment models (e.g. laserwires) Tracking in vacuum + secondaries All Geant4 physics + fast tracking in vacuum and variance reduction techniques Energy deposition based on Geant4 + Root Detector interface – Mokka and xml
30
Energy deposition, collimation, halo and backgrounds at ILCILC collimation system (top left), electron and photon halo (top right) power losses in the extraction line (bottom left), energy deposition in a final focus quadrupole (bottom right)
Start to end simulations
Several codes staged to simulate the whole accelerator, typically from injector tothe experimental station IMPACTT (Photoinjector), ELEGANT (Accelerator), Genesis (FEL process) for LCLS(Y Ding et al.) ASTRA + ELEGANT for PSI injector test facility (Y. KIM et al.) ASTRA + ELEGANT + + CSRTRACK + GENESIS for DESY XFEL MERLINbased for ILC (D. Krucker et al.) PLACET + BDSIM for CLIC (codes run in parallel, PLACET compute the wakefieldsand BDSIM tracks the secondaries and computes energy deposition)
Control Systems and online optics analysis
Control system to drive individual hardware & processes Process examples: Ramp, injection, extraction, orbit correction
Advanced concepts:
GAN (Global Accelerator Network) LHC@FNAL remote operation centre for CMS and machine https://lhcatfnal.fnal.gov/ Online models and flight simulators – virtual accelerator to plug control software
✔ optics server at PSI’s SLS, CORBAbased, for orbit correction✔ ATF2 flight simulator ✔ LHC online model
33
For complex machines the control system should be modelbased
LHC Online model
Provide virtual accelerator for software testing Virtual accelerator for safety checks during beam steering Online optics matching to help with beam steering Online optics error fitting Very detailed aperture and machine imperfection database Model corrections depending on operation conditions Clientserver architecture, javabased gui and control system interface, pythonbasedserver with MADX as the primary computation engine Ad hoc python scripting Used for LHC commissioning
35
Operator console – virtual mode
36
User interface for interactive expert mode fully exploiting the accelerator model
37
Example: injection and dump commissioning
Full aperture model for injected and circulating (including septum alignment) OM used for orbit steering to detect aperture bottlenecks (oscillating bumps) Check that the beam is steering onto a collimator when kicker off Aperture bottleneck detected based on BLM data, confirmed by radiation survey and cured by realignment Magnetic error fitting from orbit and dispersion measurements
38
Aperture measurements (arcs)
Free oscillations with different starting phases generated by OM Closed bumps for bottlenecks Looking at BLM readings
39
CMS beam crossing (from CERN logbook 03 Dec 2009)
General data management issues
Data rates/storage requirements less than HEP (even multiturn BPM data) Not talking about statistical data Data persistence not always important Smaller communities (lab staff + some external) > slow adoption of standards, frameworks etc. elogbooks common Tools: MATLAB, mathematica, root common Software development: version control and some other management procedures in place
Conclusion
Electromagnetic codes such as cst particle studio, gdfidl in place. Lackof open source frameworks (like OpenFoam form fluid mechanics which provides meshing, gui, etc.) Computeintensive gas, solid and fluid dynamics based on commercial tools such as ANSYS for targets, dumps etc. Beam optics codes – standardization/convergence a question Machinedetector interface codes present (e.g Geant4based BDSIM) Collective effects and other nontrivial beam physics codes developing. Unfortunately no frameworks available Flight simulators and online models emerging for highlevel controls Accelerator physics provides plenty of computeintensive applications