Renaming `BeginningEle`

[ax3l]

When working on the Python implementation, I noticed the following elements have inconsistent/unnecessarily abbreviated/superfluous suffixes in their names.

I would suggest the following renamings.

• BeginningEle: -> Begin or Start, (draft in standard)
  (or maybe even a generic Source of particles, as in ImpactX)
• NullEle: -> Empty
  (note: the names Null and None are reserved keywords in some of the file formats and languages that PALS supports, so we should avoid them)
• UnionEle: -> Union is not descriptive enough and a reserved class in Python typing (same for Collection); from the description, better would be Overlap Can be discussed in Girder too brief? Clarify Union #100

[DavidSagan]

These names BeginningEle, NullEle, and UnionEle will be consistent with Bmad and SciBmad. Further, using the Ele suffix makes the names more descriptive since Begin Empty and Union are rather generic.

[ax3l]

Got it. I think if we use the Ele suffix then writing non-abbreviated Element could be more readable.

In practice, the elements will always be used in the context of a beamline/PALS definition as elements and in codes are likely in some kind of element namespace. In a YAML/JSON file, it is even explicitly after kind: ... in all cases. Thus, I do feel the Element suffix does not add too much meaning, which is why we do not append it to other elements either.

[DavidSagan]

Yes Element would be more readable but I do think Ele would be good enough. Let us see what others think...

[ax3l]

After the discussion today, let us split the individual parts since they need individual discussion.

• Union/Girder: Girder too brief? Clarify Union #100
• Null/Empty: Rename: NullEle -> Placeholder Element #101
• Begin(ing): here :)

[ax3l]

@DavidSagan @jsberg-bnl from our discussion today, what do we want the BeginningEle to do? Do we want to use it as a reference point and how would it be different from how we use Markers?

Here is its draft so far: https://pals-project.readthedocs.io/en/latest/element-kinds.html#beginningele-element

[jsberg-bnl]

I started thinking about this more as the discussion went on, and I'm wondering whether doing its functionality as an element is really the right thing. Here's where I'm coming from: the purpose of the beginning element is to set initial reference parameters (energy, time, maybe a full orbit) and layout parameters (floor position). None of these is really a property of an element per se, but is a propagated property when the element is put into a branch. So shouldn't the functionality that we're trying to assign to the beginning element really be assigned to the branch? Basically "here are the reference parameters at the start of the branch" or "pull the initial reference parameters for the start of the branch from element blah."

[mattsignorelli]

I second what Scott says. SciBmad currently stores this information in the branch

[DavidSagan]

Things get complicated when stuff like Twiss parameters, orbit, or floor position are to be specified at someplace that is not the beginning of the branch. And needed is being able to designate multiple such places and to be able to switch from one to the other as the "active" element. So here is a proposal: Rename BeginningEle to something like FixerEle (since it can be used to "fix" Twiss and/or other parameters at a particular location).

[ax3l]

Voted on PALS meeting of November 5th (16 participants):

Poll options:

• with *Ele suffix -- received 1 vote
• without *Ele suffix -- received 7 votes