[Feature Request]: Proper Arc-by-Arc correction

[JoschD]

Feature Description

In the current implementation of the arc-by-arc phase-advance correction, the phase-advances per arc are simply combined to get a total phase advance per arc, which is then corrected using the standard response matrix approach.

While this might work in some cases, a more robust correction approach should do the following:

• get total phase-advance per arc (as before)
• loop over each arc
  • select only the response of the MQTs/KQTs within that arc for correction
  • solve equation system to get MQT/KQT correction value

Possible Implementation

Firstly, this requires an additional loop within the iterative global correction scheme, but that should not be too hard to implement.

Secondly, this requires the algorithm to know which MQTs are in which arcs and which knobs control them.
There are three options that I see:

• Hardcode the MQT knobs that belong to each LHC arc.

• A bit more flexible: there is unused code, leftover from BBS, to prepare for such a scenario in the accelerator class module
  

  omc3/omc3/model/accelerators/accelerator.py

  Lines 347 to 368 in 68b622b

  	class Variable:
  	"""
  	Generic corrector variable class that holds `name`, `position (s)` and physical elements it
  	affects. These variables should be logical variables that have and effect in the model if
  	modified.
  	"""
  	def __init__(self, name, elements, classes):
  	self.name = name
  	self.elements = elements
  	self.classes = classes
  	class Element:
  	"""
  	Generic corrector element class that holds `name` and `position (s)` of the corrector. This
  	element should represent a physical element of the accelerator.
  	"""
  	def __init__(self, name, s):
  	self.name = name
  	self.s = s

  
  also seen by the frm and to variables in the signature of the respective functions:
  

  omc3/omc3/model/accelerators/accelerator.py

  Lines 245 to 258 in 68b622b

  	def get_variables(cls, frm=None, to=None, classes=None):
  	"""
  	Gets the variables with elements in the given range and the given classes. ``None`` means
  	everything.
  	"""
  	raise NotImplementedError("A function should have been overwritten, check stack trace.")
  	@classmethod
  	def get_correctors_variables(cls, frm=None, to=None, classes=None):
  	"""
  	Returns the set of corrector variables between ``frm`` and ``to``, with classes in
  	classes. ``None`` means select all.
  	"""
  	raise NotImplementedError("A function should have been overwritten, check stack trace.")

  
  As far as I can tell, this functionality has never been used, but we could activate it to define corrector classes with locations, which would again need to be hard-coded into the accelerator they belong to.

• An even more flexible way, which would allow users to implement arbitrary correction knobs, could be to ask the model directly: while not easily possible in madx, cpymad as well as xsuite have features that quickly give you the magnets that are steered by a knob and one could filter then by their location. This implementation needs a full re-write of the model creation and global correction with one of those simulation tools, and I guess the idea would then be for the global correction to create an accelerator instance at the beginning of its run and hold this in memory until the end.
  This would also allow avoiding all the read/write of the global correction, but implementing parallel running might be a bit more cumbersome.

To be evaluated and should probably be split up into smaller issues. Feel free to link them here then.