[Feature Request]: XSuite Integration

[JoschD]

Feature Description

At some point we should change our model creation to XSuite, as it will provide some advantages over using MAD-X and the latter will also be slowly phased out. This Issue is trying to summarize the steps needed to make this happen, but also the requirements to be met beforehand and serves as a gathering point for ideas what a change to Xsuite might actually accomplish - as simply replacing MAD-X with Xsuite will not get us any benefits and retrofitting it later on will probably be more work than thinking about it beforehand.

Please Edit this Comment to add new ideas/concerns/features

External Requirements to be met

• Stable releases of Xsuite: So far there are a lot of breaking changes with new releases in Xsuite, which would mean constant adaptation on our side as well. Once the package is more mature, these should become less.
• acc-models providing sequences and optics in Xsuite format: For now the sequence and optics are still provided in MAD-X format. The sequence can nowadays be read by Xsuite, but the optics (i.e. the files in acc-models-lhc/operation/optics) are using multiple layers of calls to MAD-X files, which for now need to be handled by a MAD-X instance
• Coupling Columns in Twiss Output: This is not neccessarily a requirement, as they are usually 0 in all our models, so you could just add 0 columns (as omc3 expects the columns to be present for the DELTA calculations.) But it would be nicer to have actual values from the model, in case this might be needed later on and the person running the study does not know about the 0-column hack. There is already a PR: Implement coupling Edwards-Teng R matrix elements in twiss xsuite/xtrack#667
• AC-Dipole: We need to be able to have an AC-Dipole in the model, in particular for the AC-Dipole compensation that we are doing.
• (Possibly) Installation of errors from error tables: While not explicitly necessary for omc3, in general the work with Xsuite will only be possible for the OMC studies, when we can load the WISE tables into our models. The current state is, that Frederik has written some basic functionality for that, which IMHO follows too closely the MAD-X implementation of these macros and should be re-written clearer and more pythonic.

Benefits of using Xsuite in omc3

General benefits

• Everything can be pure python. No more writing MAD-X scripts from python and calling external MAD-X processes.

Benefits that require some restructuring

It should be defined before the change to Xsuite which benefits should be gained from it and the implementation coordinated along these lines, as otherwise changing the code later again will mean twice the work (if it will ever be done).

• Load from .json: Instead of creating a new model from scratch every time we need it, we can save a model_nominal.json in the model directory, which we can load to make sure the next steps (e.g. global correction) will be performed on the exact same settings.
• Create models for both beams at the same time: While this was in principle already possible in MAD-X it will be easier to do with Xsuite. It will require some rethinking of the main model creator function (and how it is called from the GUI).
• Proper Arc-by-Arc correction, see [Feature Request]: Proper Arc-by-Arc correction #480
• Quicker FullResponse creation, as we do not have to create the model every time but either could load the .json or maybe parallelize this somehow completely from the same process? Not sure how this might be supported in Xsuite (or general python parallelism), but spawning N-processes manually feels like a lot of overhead. Related issue: [Maintenance]: Make Response Creation its own ModelCreator #484

Possible Pitfalls

• Beam 2: I think omc3 operates on the assumption, that the model given is a MAD-X-style "Beam 2" model, i.e. with elements in the same direction as Beam 1, while the second Beam in Xsuite is a MAD-X "Beam 4" equivalent. To be checked! (See related issue [Bug]: Beam direction possibly wrong for Beam 4/Beam 2 tracked backwards #475)

Possible Implementation

For a summer-student project I wrote some functionality that basically does what the model-creator does, but starts in cpymad and goes then quickly to Xsuite. This might be useful as a starting point (but you need to replace my LHCBeam dataclass with the omc3 Accelerator-Class):

https://github.com/JoschD/xsuite_lhc_tests/

Main file:
https://github.com/JoschD/xsuite_lhc_tests/blob/main/lhc_single_beam.py

[rdemaria]

I am carrying out substantial work to port acc-models-lhc to Xsuite. The work can be tracked in the package https://github.com/rdemaria/lhcoptics.

There will be two main access mode, one for simple consumption and one for development. Work is in progress, I propose to meet sometime end of August.

Example for direct acc-models access:

import xtrack as xt

lhc = xt.load("https://acc-models.web.cern.ch/acc-models/lhc/2025/xsuite/lhc.json")
lhc.vars.load("https://acc-models.web.cern.ch/acc-models/lhc/2025/scenarios/cycle/pp/ramp/0/optics.madx") 
lhc.b1.twiss().plot()

Example dev:

from lhcoptics import LHC as LHCDev

LHCDev().y2025.pp.ramp[0].ir5.plot()