Fix BeamLine name attribute

[EZoni]

Overview

With the implementation in the main branch, if we add a name attribute to the line object created in the FODO example, the attribute is ignored and the output is

kind: Line
line:
- drift1:
    kind: Drift
    length: 0.25
- quad1:
    MagneticMultipoleP:
      Bn1: 1.0
    kind: Quadrupole
    length: 1.0
- drift2:
    kind: Drift
    length: 0.5
- quad2:
    MagneticMultipoleP:
      Bn1: -1.0
    kind: Quadrupole
    length: 1.0
- drift3:
    kind: Drift
    length: 0.5

This is not consistent with the example in https://github.com/campa-consortium/pals/blob/main/examples/fodo.pals.yaml.

With the implementation in this branch, if we add a name attribute to the line object created in the FODO example, the attribute is stored and the output is

fodo_cell:
  kind: BeamLine
  line:
  - drift1:
      kind: Drift
      length: 0.25
  - quad1:
      MagneticMultipoleP:
        Bn1: 1.0
      kind: Quadrupole
      length: 1.0
  - drift2:
      kind: Drift
      length: 0.5
  - quad2:
      MagneticMultipoleP:
        Bn1: -1.0
      kind: Quadrupole
      length: 1.0
  - drift3:
      kind: Drift
      length: 0.5

which is consistent with the example in https://github.com/campa-consortium/pals/blob/main/examples/fodo.pals.yaml.

This is achieved primarily by deriving the Line (BeamLine after #15) class from the base element class BaseElement instead of deriving it from Pydantic's base model class BaseModel.

I also merged the custom field validation of the line field with the custom model validation, since we needed one anyways to fix the deserialization. I don't see why they should be separate.

I wonder if the right way to do this is using @model_serializer instead of @model_validator...

To do

• Serialization (fixed with c391e43, very few lines changed)
• Deserialization (fixed with the custom model validator, many more lines changed)
• Cleaning

[EZoni]

yaml_data was a dictionary before, now it's a one-element list. Keeping the previous API for the Line constructor requires more work, which could be done in this PR or in a separate PR. I have not tried it yet (i.e., I don't know yet if I can find a way to make it work).

[ax3l]

@EZoni does this need a rebase?

[EZoni]

Probably yes, after the last few commits in main. I will get to it asap.

[EZoni]

@ax3l

Conflicts fixed.

[ax3l]

This makes me think, also for our current layout/draft:

• should a PALS file support having multiple beamlines (segments: yes)?
• if not, which one is the "entry point" to use by default? The 0-th element might be a lattice element and not a kind: BeamLine once we support inheritance

Ignoring the entry point question, we might need a "wrapping" LatticeElements class here in Python that can load a list of elements (instead of only loading [0] and assuming it is of kind BeamLine)

[EZoni]

I pushed a change in 464020d to return a dict instead of a single-element list.

I cannot remember where the single-element list came from, but the new change seems to avoid the API issue. Am I overlooking something?

I'm not sure I understand what the LatticeElements class should be, but maybe it could be done in a separate PR, unless it turns out that it's necessary here.

[EZoni]

If the problem was with the serialization of single elements, maybe it should be fixed separately as well.

[ax3l]

From the PR description:

I wonder if the right way to do this is using @model_serializer instead of @model_validator...

This is what I found:

The pydantic serializer is how we go from pydantic classes to dicts / json and back. This is needed when we want to rename fields or do custom conversions that are serialized slightly different than the internal representation. It looks to me like this is primarily for output formatting changes, not input.

The pydantic validator is used for custom validation logic, e.g., when someone sets a field/value/property, and can optionally modify values. But it seems this is also used for input changes...

[ax3l]

Excellent, thank you!