iFAST 5.3 (Slow Extraction) - Initial Meeting

Thursday 27 Oct 2022, 16:00 → 17:20 Europe/Zurich

Francesco Maria Velotti (CERN)

16:00 → 16:10 Welcome and Introduction

Speaker: Francesco Maria Velotti (CERN)

ifast_wp3_intro.pdf

Welcome and Introduction

Francesco Velotti

Classification

• Comparing accuracy vs speed
• Loss estimation: Can be combined with matter tracking (FLUKA, Geant4)
• No real improvements to be found on smaller machines?

Moving Forwards

• Accurate simulations with Xsuite - powered by GPU
• Extensible - can be used with pyCollimate (but is not GPU ready), or Geant4

Working Group goals

• A community for SloEx simulations
• Share tools and collaborate
• Can we exploit ML?
• Series of informal discussions
• Ideally sharing git projects
• Meetings every few months, or more frequent if needed

Questions

• Do we have a list of GitLab/GitHub projects?
• Codes for crystal bending - what do we have?
• Kevin Brown - working with a NASA group working on steering comic rays with crystals - could the same tools be used
• Next meeting - could everyone prepare one slide giving an overview for what everyone is working on?
  • Could we come up with a template of questions to answer?
  • There is also BDSIM - this can be used with GMAD
  • Collimation group in ABP
  • Crystal collimation can be done with SixTrack with K2 engine, or FLUKA, or BDSIM
  • This can be exported to Xsuite - still on going and crystal routine in K2 still not bechmarked with FLUKA
  • FLUKA can simulate interactions of particles with crystals
  • Measure response of the crystal, build a Probability Density Function
  • Use that in any simulation code - this is what we do in pyCollimate and mapTrack
  • We should keep track of our tools and what we use them for.
  • A list of techniques, or things people are struggling with.
  • Linking every presentation with a git repo, with examples

16:10 → 16:40 Introduction to Xsuite (+10m discussion)

Speaker: Giovanni Iadarola (CERN)

000_Xsuite_ifast.pdf

000_Xsuite_ifast.pptx

Introduction to Xsuite

Giovanni Iadarola

• Xsuite begun at the beginning of 2021

Motivation

• There were many independently developed multi-particle tracking softwares with different features
• The learning curves are long and specific
• Difficult to define a consistent strategy with future challenges - such as FCC, muon collider
• Opted to start with a new design considering all requirements
• No need to start from scratch - reuse experience and sometimes source code

Requirements

• Sustainable
  • The community is relatively small
  • Need something easy to maintain and develop
  • Favoured mainstream technology: python
  • Keep the code simple and slim: student friendly
• Easy and flexible to use: scriptable
• Speed matters
  • Maintain performance with sixtrack on CPU and sixtracklib on GPU
• Provide GPU interface

Structure

• A set of python packages
• Already used in BE-ABP
• Newcomers are often aware of python, a short learning curve
• Python is easily extended with C, C++, and FORTRAN
• Support GPUs, as some simulations can only be done on GPUs
• Complicated market situation
  • No accepted standard
• Multiplatform code: support multiple vendors
• New standards are already expected
• Open source GPU packages leveraged

Development

• Demonstrated a short learning curve
• Already used in production for some studies
• Users encouraged to contribute with code, tests, documentation etc

Collective Effects

• Xsuite can handle collective elements - impedance, space-charge etc
• The code is aware of these elements, where the action on one particle depends on the coordinates on the other
• No special action required by the user - the code automatically handles asynchronicity

Interface

• Built to be as extensible as possible
• Any element that has a tracking method is a valid element for Xtrack
• In particular, PyHEADTAIL elements are valid - but currently need a compatibility mode

Comparison and Advanced Features

• Extremely small errors when checking against SixTrack (machine precision)
• Similar compilation time to SixTrack
• Already used in Dynamic Aperture studies (with a fully pythonic approach)
• Use of ML for smart sampling of phase space
• Feedback: Xsuite was fundamental for these projects

How it works

• Searches 6D closed orbit
• First order turn matrix
• Eigenvector tracking of particles
• Compute twiss parameters from eigenvalues (bonus)
• Repeat off-momentum for chromaticity
• Tested for HL-LHC, PSB, ELENA, Elettra, CLIC-DR, FCC-ee

Xdeps

• Deferred expressions from MAD-X
• Knobs imported from MAD-X can be easily changed before the simulation or during the simulation
• Variables can also be inspected - very powerful

Synchrotron Radiation

• Not available in SixTrack
• Full quantum description
• Xtrack twiss computes energy loss

Xcoll

• Installs collimators in Xsuite beamlines
• Configures the gaps based on user configuratoin
• Different particle-matter simulation engines
  • K2 ported from sixtrack
  • Geant4-BDSIM tested in full loss-map studies
  • FLUKA
• More modules for precisely locating particle loss
• still not implemented

Experience

• Modular code is feasible
• Different computing platforms can be supported under the same codebase
• Gently moving towards production

Questions

• Pulling in geometry from CAD files is not currently available
  • This can be done with FLUKA
• Does the code interface or link with many existing libraries?
  • Single particle: ported from SixTrackLib directly
  • Space charge: written from scratch, but inspired by PyHEADTAIL
  • Collected effects: interface with PyHEADTAIL
• Elements: thintracking, so in the end everything is a multipole
• Sequences can be imported from MAD-X
  • It is imported from cpymad sequence object
• Any disadvantages with MAD-X?
  • MAD-X is limited with space charge
  • No real disadvantages
  • MAD-X might take longer to import files
  • Do the import once, and export
• MAD-X imports - do deferred expressions impact performance
  • We do pull, not push
  • The deferred expressions are not read every time, they are requested
  • They do not impact performance during tracking
• What does the ‘X’ stand for?
  • Nothing!
• PyOrbit - what are the prospects of using it? Is it being phased out?
  • Trying to phase applications out of pyOrbit
  • Investment has been made into Xtrack
• Can the variations of components be saved in Xdeps
  • The idea is that things can be changed with complex rules while the simulation is running
• Xtrack does not use the same API as MAD-X, but in principle they are equivalent in capabilities
• How are you handling support?
  • Documentation
  • GitHub issues, classified as blocking or feature requests
  • Might be nice to have a tutorial for the next workshop?

16:40 → 17:10 First look at Xsuite for Slow Extraction (+10m discussion)

Speaker: Pablo Andreas Arrutia Sota (University of Oxford (GB))

iFAST_xsuite_27102022.pdf

iFAST_xsuite_27102022.pptx

First look at Xsuite for Slow Extraction

Pablo Andreas Arrutia Sota

• A small example with slow extraction with SPS
• Very easy to get started with the documentation and examples
• Xsuite is the new player in the zoo of simulation software

Key Features

• GPU support
• Easy for time-dependent
• Active community
• Easy to combine with particle-matter software

Benchmarking Test

• Very simple SloEx sim with
  • MAD-X Thintrack
  • Xsuite direct import from MAD-X
  • Henontrack (linear transport + virtual sextupole)
• Looking at small amplitude phase-space portait: very similar charachteristics
• Separatrix arm: important for loss studies
• Good agreement with Xsuite and MAD-X
• Henontrack cannot reproduce amplitude detuning so some errors are expected
• Great agreement with MAD-X and Xsuite when looking closer

Transit Time

• Important for time structure and spill quality studies
• 100 particles simulated, plotted the time taken to leave the machine
• Perfect agreement with Xsuite and MAD-X
• Henontrack also performs well for small transit times

Ripple Mockup study

• Add a 50hz pertubation
• Over 400 quads in the machine but can be trimmed together

Conclusion and next Steps

• Easy importing from MAD-X to Xsuite
• Xsuite and MAD-X are in great agreement
• Time-dependent parameters easily implemented
• Looking at implementing pyCollimate

Questions

• Slide 11: time dependent studies. Other parameters like RFKO can be handled similarly.
  • Longitudinal coordinates are accessible
  • Depending on what the change is - if it is a fast change, it is not equivalent
  • If it is a slow change, it is the same idea
  • A possibility to code it yourself, take voltage as a function of z
• Do you have RF cavities that you can track longitudinally? Can you track outside the bucket?
  • Tracking can be done for a few turns outside the bucket
  • One possibility is to introduce a periodicity
  • These SloEx simulations were done debunched
• RFKO: typically frequencies are lower, arrival time doesn’t matter, as a practical simplification
• How many turns have we tried?
  • No real limitation
  • ~30 million have been done for LHC
• Question: tracking on transfer lines?
  • Discussing this currently
  • Twiss can be given as initial conditions
  • Slowly getting there
  • Putting together a use-case would be useful for example
• How do you know that after a million turns things are correct?
  • Check for symplectic response matrix
  • Maps are symplectic by construction
  • Compare to other codes (SixTrack)
  • Convergence checks by changing the number of slices
• Is it possible to have a 3D field map?
  • We already have 2D time dependent map, implemented in a symplectic way
  • Ideas of 3D static map

17:10 → 17:20 Benchmarking Xtrack and MAD-X on SWAN

Speaker: Thomas Bass (University of London (GB))

2022-10-27-iFAST-5-3.pdf

2022-10-27-iFAST-5-3.pptx