Element types and properties

[danielkallendorf]

I've spend some thoughts on the current architecture of the standard:

We have the type of an element, but we are also developing parameters/parameter-groups.
Our current approach seems to be, to explicitly define the possible properties of an element.
This appears to be standard practice in most lattice-codes and it is also reflected in the pals-python models.

My question for discussion is: Do we actually need Element Types?
What is a quadrupole, if not a space with a quadrupole field?

While designing this standard, we will have to allow every property for an element explicitly:

Bend:
    name
    BendP
    MagneticMultipoleP
    ApertureP
    MatterP
    ....

Quadrupole:
    name
    MagneticMultipoleP
    ApertureP
    MatterP
    ....
....

This will

1. lead to discussions like "Is my magnet allowed to have matter properties"? Or vice versa.
2. lead to many models with slightly different allowed parameters.

Based on this line of thinking, it might be enough to define the parameters in this standard and allow generic Elements to have them. This would reduce the complexity.

It is still be useful to have a type (or purpose?) field which hints the intended use, but this is far less restricting.

A file then would consist of

Element:
    name: MyQP4
    purpose: Quadrupole
    MagneticMultipoleP:
        ....
    ApertureP:
        ....

In a next step one could then even use the name of the element as key, which would resolve the issues and required workarounds with the yaml-format in pals-python.

MyQP4:
    purpose: Quadrupole
    MagneticMultipoleP:
        ....
    ApertureP:
        ....

[danielkallendorf]

sorry. move to standard repo