Type of an element vs parameters

[danielkallendorf]

There are some interesting implication form this discussion #52

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.

[DavidSagan]

One issue here is that if a generic element has, for example, bend and RF parameters how does a program handle this?

[danielkallendorf]

That means someone is having a bend cavity, because they are for example trying to describe a cyclotron.
A program can handle this either:

• By having a dedicated bend-rf element
• By superimposing elements/fields
• By calculating thin alternating slices of RF and bend
• ...
  We have decided, that it's the programs job to handle the implementation and physics.
  There will always be combinations which are not supported by some programs.

[DavidSagan]

If someone is trying to describe a cyclotron, the BendP and RFP parameter groups will not be adequate. There is also an issue in that for the standard to work, everything must be well defined. An things get complicated when going to a bend coordinate system. Just look at the bend multipole documentation in PR #54.

[DavidSagan]

Thought: One way to handle overlapping fields is to have a UnionEle which can have a collection of sub elements:

UnionEle:
  Name: acc23
  RFCavity:
    ...
  Solenoid:
    ...
  ...

In this example, UnionEle consists of an RF cavity overlapping a solenoid.

Constructing overlapping fields this way gives great flexibility in terms of misaligning fields and even the length of the individual fields do not have to be all the same.

[mattsignorelli]

@danielkallendorf 's suggestion is currently how SciBmad implements elements. In my view it is the most flexible and also the simplest since there isn't a bunch of combinations of allowed/disallowed parameter groups for different element "kinds". Adding functionality or a new parameter group doesn't then require modifying every single element.

Also, combining RFP with BendP seems perfectly fine, if a code can simulate, why not allow it?