Feature: CFM Refurbishment and Multipole Mapping Renaming

[gupichon]

Description, motivation and use case
Following the discussions in issue #299, this sub-issue focuses strictly on the cleanup, refurbishment, and syntax improvement of the Combined Function Magnet (CFM) configuration.

The goal is to move away from rigid, hardcoded multipole keys (B0, A0, B1, etc.) towards a more readable, component-oriented syntax, while eliminating code and configuration duplication between the CFM magnets and their underlying models.

Proposed solution

1. Unified Mapping Syntax (Renaming)

Instead of using abstract polynomial coefficient names in the configuration file, the mapping will now use the explicit component/class names. This improves readability for users and simplifies internal code routing.

Before:

- type: pyaml.magnet.cfm_magnet
  name: SH1_COR_001
  mapping:
    - [B2, SH1_COR_001.sextupole]
    - [B0, SH1_COR_001.hcorrector]
    - [A0, SH1_COR_001.vcorrector]

After:

- type: pyaml.magnet.cfm_magnet
  name: SH1_COR_001
  mapping:
    - [Sextupole, SH1_COR_001.sextupole]
    - [HCorrector, SH1_COR_001.hcorrector]
    - [VCorrector, SH1_COR_001.vcorrector]

2. Model Duplication Cleanup

• Remove the duplicate multipole declarations currently shared between cfm_magnet and its model.
• The model should solely be responsible for computing the conversion from hardware units (e.g., current/voltage) to physics units, without redundant configuration blocks.

3. Core Behavior Preservation

• No KickAngle Integration: As agreed, we will keep using PolynomA[0] / PolynomB[0] (integrated strengths/angles) for correctors within pyAML. A specific handling of KickAngle for AT's CorrectorPass is out of scope and will be treated later if needed.
• No Higher-Order Polynomials (>3): This remains a topic for the error/commissioning layer (sr.errors) and is excluded from this control system refurbishment.

Describe alternatives you've considered
See issue #299

Example

- type: pyaml.magnet.cfm_magnet
  name: COR_013
  mapping:
  - [HCorrector, COR_013.hcorrector]
  - [VCorrector, COR_013.vcorrector]
  model:
    type: pyaml.magnet.identity_cfm_model
    units: [1/m, '1']
    physics:
    - AN13-AR/EM-COR/CH.01/strength
    - AN13-AR/EM-COR/CV.01/strength

Additional context
See issue #299

Checklist

• I've assigned this issue to a project
• I've @-mentioned relevant people

[gupichon]

@JeanLucPons, @TeresiaOlsson @kparasch @gubaidulinvadim @GamelinAl

[JeanLucPons]

Seems ok to me.

[TeresiaOlsson]

For me too. What names do you plan for the skew components? Something like skewsextupole or skew_sextupole?

[JeanLucPons]

I expect the existing python class:

unction_map: dict = {
    "B0": HCorrector,
    "A0": VCorrector,
    "B1": Quadrupole,
    "A1": SkewQuad,
    "B2": Sextupole,
    "A2": SkewSext,
    "B3": Octupole,
    "A3": SkewOctu,
}

The above map will vanish.

[kparasch]

It looks ok to me too, but I would like a clarification on the model duplication cleanup.

Many cfm magnets are built so that e.g. Dipole and Quadrupole components are linked to one power-supply.
I imagine a suitable model will still be able to handle this link. Is this correct?

[TeresiaOlsson]

I expect the existing python class:

unction_map: dict = {
"B0": HCorrector,
"A0": VCorrector,
"B1": Quadrupole,
"A1": SkewQuad,
"B2": Sextupole,
"A2": SkewSext,
"B3": Octupole,
"A3": SkewOctu,
}

The above map will vanish.

Maybe SkewQuad etc should be SkewQuadrupole to make the names consistent? Or alternatively accept both Quad and Quadrupole as names.

[JeanLucPons]

It looks ok to me too, but I would like a clarification on the model duplication cleanup.

Many cfm magnets are built so that e.g. Dipole and Quadrupole components are linked to one power-supply. I imagine a suitable model will still be able to handle this link. Is this correct?

Our DQ fit in this model but the model are for the moment limited to CFM on one single element and however invertible model.
The refurbishment proposed should not bring more limitation expect that you will have to know the order of your mapping when developing a model, which will be implicit.

[gupichon]

Maybe SkewQuad etc should be SkewQuadrupole to make the names consistent? Or alternatively accept both Quad and Quadrupole as names.

I may create a fallback to the correct class for some known cases (SkewQuadrupole -> SkewQuad). I'll see when l'll work on that part...