[Paper Review] Dynamic simulations in SixTrack

Kyrre Sjobak, Veronica Olsen+7 more|arXiv (Cornell University)|Aug 19, 2018

Radiation Therapy and Dosimetry8 references3 citations

TL;DR

This paper presents the DYNK module in SixTrack, a dynamic particle tracking extension that enables turn-by-turn modification of element settings—such as kick strengths or frequencies—for simulating complex beam dynamics phenomena like crab cavity failures, beam scrapers, and RF detuning. The module supports extensibility through user-defined functions, real-time element updates, and integration with checkpointing and collimation workflows.

ABSTRACT

The DYNK module allows element settings in SixTrack to be changed on a turn-by-turn basis. This document contains a technical description of the DYNK module in SixTrack. It is mainly intended for a developer or advanced user who wants to modify the DYNK module, for example by adding more functions that can be used to calculate new element settings, or to add support for new elements that can be used with DYNK.

Motivation & Objective

• To enable dynamic, turn-by-turn modification of beam element parameters in SixTrack simulations.
• To support advanced studies of beam dynamics phenomena such as crab cavity failures, beam scrapers, and RF detuning.
• To provide a modular, extensible framework for developers to add new mathematical functions and element types.
• To ensure compatibility with SixTrack's collimation version and checkpoint/restart functionality.
• To improve code maintainability by decoupling dynamic element logic from core tracking routines.

Proposed method

• The DYNK module uses a Fortran-based architecture with a central module (dynk.s90) managing function definitions and element state updates.
• User-defined functions (e.g., FILE, LIN, ADD) are parsed at initialization via dynk_parseFUN and stored in structured arrays (funcs_dynk, fexpr_dynk).
• Function values are computed on-the-fly during tracking using dynk_computeFUN, which supports recursive function calls with turn-dependent evaluation.
• Element settings are updated via dynk_setvalue and retrieved via dynk_getvalue, with state persistence across restarts.
• The system supports dynamic reference energy changes via GLOBAL-VARS and integrates with the collimation version’s multi-sample tracking.
• Debugging, file output (dynksets.dat), and restart capabilities are managed through configurable flags (ldynkdebug, ldynkfiledisable).

Experimental results

Research questions

• RQ1 How can particle tracking simulations dynamically adjust element parameters on a turn-by-turn basis to model real-world beam physics effects?
• RQ2 What architectural patterns enable extensibility for adding new dynamic functions and element types in SixTrack?
• RQ3 How can DYNK support complex workflows such as beam collimation with multiple particle samples and restartable simulations?
• RQ4 What performance and correctness guarantees are needed when modifying beam element parameters during tracking?
• RQ5 How can the DYNK module be extended to support future beam dynamics studies, such as beam-beam interactions or non-integer turn shifts?

Key findings

• The DYNK module successfully enables dynamic, turn-by-turn updates of beam element parameters, supporting simulations of crab cavity failures, beam scrapers, and RF detuning.
• The module’s modular design allows developers to extend functionality by adding new function types (e.g., random distributions) and element types without modifying core tracking logic.
• Support for the collimation version of SixTrack ensures correct behavior across multiple particle samples, with DYNK state reset at the start of each sample.
• Checkpointing and restart functionality are fully supported, with DYNK state (including function parameters and element settings) preserved and restored.
• The use of a centralized function evaluation system with recursive calls enables complex dynamic behavior, such as ripple effects or time-varying kicks.
• The architecture reduces code duplication by allowing dynamic reference energy changes, potentially enabling removal of redundant tracking subroutines like thin6dua and thck6dua in the future.