Types of elements defined by the Standard.

[DavidSagan]

Below is a tentative list of what elements should be defined in the Standard. This list is not exhaustive (this is just the beginning and I expect that there are more elements added). Also I am not sure whether it is better to have both Multipole (which has zero length) and ThickMultipole (which has non-zero length) or just have a Multipole element that can have zero or finite length. Similarly, Collimator and Mask could be combined into one element. Any thoughts on all this is appreciated.

ACKicker            "Time varying kicker."
BeamBeam            "Colliding beam element."
BeginningEle        "Initial element at start of a branch."
Bend                "Dipole bend."
Collimator          "Collimation element."
Converter           "Target to produce new species. EG: Positron converter."
CrabCavity          "RF crab cavity." 
Drift               "Field free region."
EGun                "Electron gun."
Fiducial            "Global coordinate system fiducial point."
FloorShift          "Global coordinates shift."
Foil                "Strips electrons from an atom."
Fork                "Connect lattice branches together."
Girder              "Support element."
Instrument          "Measurement element."
Kicker              "Particle kicker element."
LCavity             "Linac accelerating RF cavity."
Marker              "Zero length element to mark a particular position."
Mask                "Zero length collimator."
Match               "Orbit, Twiss, and dispersion matching element."
Multipole           "Zero length multipole."
NullEle             "Placeholder element used for bookkeeping."
Octupole            "Octupole element."
Patch               "Reference orbit shift."
Quadrupole          "Quadrupole element."
RFCavity            "RF cavity element."
Sextupole           "Sextupole element."
Solenoid            "Solenoid."
Taylor              "General Taylor map element."
ThickMultipole      "Multipole with non-zero length."
Undulator           "Undulator."
UnionEle            "Container element for overlapping elements." 
Wiggler             "Wiggler."

[DavidSagan]

And some more elements to add to the list:

Crystal                     "X-ray Diffraction crystal"
Mirror                      "X-ray mirror"
MultiLayerMirror    "Mirror made up of multiple layers."

[freddieknets]

Is there an approach for overlapping definitions? I'm thinking for instance about Crystal which in the SPS/LHC context means something completely different (it is used to deviate particles in an efficient manner using crystal channelling).

[DavidSagan]

@freddieknets There should be different names here. How about CrystalChannel for crystal channeling? In general, there will need to be an interface layer between any program and the standard to sort out naming issues units issues, etc.

[freddieknets]

I agree that the names should be different; I guess the question is more philosophical. How to avoid naming confusion? As on our side we seeCrystal as a channelling one, our team members might get confused when reading lattices from the standard, assuming the Crystals to be channelling ones. Similarly, other people would get confused if Crystal would refer to a channelling crystal while they expect an X-ray crystal. I don't have a strong opinion on either, I was just wondering if we decided on a default strategy for this type of situations. Like, avoid any generic name? Or choose one of the tracking codes as the main naming reference?

[DavidSagan]

One possibility is to avoid the name Crystal altogether and use something like CrystalChannel and DiffractionCrystal.

[DavidSagan]

Also I propose element type names be upper camel case (camel case with first word capitalized).

[ax3l]

I would really like to add a "Source" element, to incorporate the ad-hoc definition of initial beam distributions (and loading from files) self-consistently. (Generalized EGun?)

[ax3l]

Thin vs. Thick elements.

We often can systematically create thick elements from thin approximations. Should we just consistently prefix the zero-length elements Thin...? Even better might be to add an attribute (is_thin = true/false) as in MADX.

[danielkallendorf]

organize elements in a tree?

[ax3l]

Laurent Deniau:
Link to the hierarchy of elements in MAD-NG https://github.com/MethodicalAcceleratorDesign/MAD-NG/blob/455e357c6feca055ac49424547263ae8909fe6b3/src/madl_element.mad#L166

[cemitch99]

What did you have in mind as the properties of the Match element here? Most of the elements listed correspond to physical structures with geometry and field properties, but a few correspond (like this one) correspond to processes. Should there be some distinction?

[DavidSagan]

@cemitch99 What is meant by "distinction" here?

[cemitch99]

There was discussion on making the standard (for describing the physical lattice layout) agnostic to details of the beam dynamics itself. Match is an interesting case -- a process that involves an optimization of some lattice parameters to achieve a certain beam dynamics aim -- so to me it's not clear if/how it should be part of the standard. To me this is a more "high-level" process that a code does with a lattice. Maybe we could either remove it or create another category, like Elements and Actions?

[DavidSagan]

My thought was to define a Match element to take Twiss parameters for the start and end of the element and these would be used to compute a transfer matrix. No tracking would be needed. And I do agree that it is important to make the lattice standard independent of tracking.