iFAST 5.3 (Slow Extraction) - Initial Meeting
→
Europe/Zurich
Francesco Maria Velotti
(CERN)
Description
Registration
Participants
-
-
16:00
→
16:10
Welcome and Introduction 10mSpeaker: Francesco Maria Velotti (CERN)
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) 30mSpeaker: Giovanni Iadarola (CERN)
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) 30mSpeaker: Pablo Andreas Arrutia Sota (University of Oxford (GB))
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 10mSpeaker: Thomas Bass (University of London (GB))
-
16:00
→
16:10