Feature: CFM Refurbishment and Multipole Mapping Renaming

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

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]

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.

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

@JeanLucPons

@JeanLucPons, @TeresiaOlsson @kparasch @gubaidulinvadim @GamelinAl

Seems ok to me.

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

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.

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?

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.

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.

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...

If we have alias, then I would add:

HDipole -> HCorrector
VDipole -> VCorrector

For a ramped accelerator (e.g. booster), it makes more sense to talk about controlling dipoles

@GamelinAl

@GamelinAl
In fact for controlling dipole we have an opened issue #136 concerning energy change.
Dipole and Corrector are different. We expect that controlled dipole depends only on Brho while a Corrector will depend on both Brho and angle.

@gupichon-soleil

@gupichon-soleil Is this issue still relevant?

@gubaidulinvadim

@gubaidulinvadim Nope

Navigation Menu

Repository navigation

Feature: CFM Refurbishment and Multipole Mapping Renaming #302

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature: CFM Refurbishment and Multipole Mapping Renaming #302

Description

Activity

gupichon commented on Jun 26, 2026

JeanLucPons commented on Jun 26, 2026

TeresiaOlsson commented on Jun 26, 2026

JeanLucPons commented on Jun 26, 2026

kparasch commented on Jun 26, 2026

TeresiaOlsson commented on Jun 26, 2026

JeanLucPons commented on Jun 26, 2026

gupichon commented on Jun 26, 2026

GamelinAl commented on Jun 30, 2026

JeanLucPons commented on Jun 30, 2026

gubaidulinvadim commented on Oct 13, 2026

gupichon-soleil commented on Oct 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions