* Some element parameter groups may or may not be present. EG: AmpVsTimeParams for ACKicker. 

* EG AmpVsTimeParams: There are no "shortcuts" like ele.L -> ele.LengthParams.L. Can set via:
  at = ele.AmpVsTimeParams    # Does this work if AmpVsTimeParams is not present? If so need function for this.
  at.interpolation = ...
or
  at = AmpVsTimeParams(t_offset = ...)
  at.interpolation = ...
  ...
  ele.AmpVsTimeParams = at

* BeamBeam element can have a reference to a Solenoid element 

* Display (show) of parameter groups that have substructures.

Coordinate System Names:
	Global coordinates  -- Same as current
	Machine coordinates -- (x,y,s) curvilinear coordinates with s measured from the start of the lattice branch. Currently called Laboratory coordinates or Local coordinates. Note: Will be left handed for elements with orientation = -1.
	Body coordinates  -- Same name as existing
	Local coordinates -- (x,y,s) curvilinear coordinates with s measured from entrance end of element. Will always be right handed. Will be equal to Body coords if there are no misalignments.



* If an element is inserted in multiple places in the lattice, or for multipass lord/slave and super lord/slave pairs, the corresponding elements in the lattice are shallow copies of one another (a copy at the ele.pdict level is made but all pdict parameters are not copied). Since all element parameter group structs are immutable, even though elements may only be shallow copies of one another, it is not possible for changes to parameters a parameter group for one element to affect the values of the corresponding parameter in any other element. For example, changing the value of multipole K1 in one element will not affect the K1 of any other element. 

The reason for doing a shallow copy, instead of a deep copy, is to save on memory in case large amounts of the same data have to be associated with multiple elements. A common example is the storage of magnetic or electric field tables. In such a case, it may be possible for changes to one element affecting other elements. 

* NaNs for x_limit / y_limit mean there is no limit. Also used for patch parameters E_tot_offset, E_tot_exit, and pc_exit.

* Stuff marked "Internal" are primarily meant for internal use by AcceleratorLattice functions and are probably not of interest to the average user. Internal names are not exported with a using statement and if an internal is used, a "AcceleratorLattice." prefix must be used to access.

* Unlike Fortran Bmad, Julia Bmad is entirely case sensitive.

* Explain @kwdef macro for structs.

* Explain how to add custom attributes to an element:
    * How to extend the list of official attributes
    * What functions to extend.

* Explain that AcceleratorLattice.jl can be used standalone.

* ele.field_master: Only used if p0c changes. Default is false. (what group does this go into?)
* Bend .type attribute: Only used if rho, angle, g, bend_field changes.

* Explain about switches and how to extend them.
    switch_list_dict   -- List all switch groups and values (Using symbols).

* Element grouped and ungrouped parameters.

* Explain that overloaded dot selection "ele.who" is used to ensure some bookkeeping done in background.

* "Lattice" bookkeeping triggered by user (or optimizer).
* Drifts are temporarily put in branch.ele_saved for superposition.

* MultipassLord elements do not have orientation, s, nor s_downstream parameters but does have a LengthParams

* Lattice bookkeeping can be bypassed by setting the element group parameter directly.

* Old Bmad roll is "tilt" in new bmad.
* Bend x_rot and y_rot are about the chord center and not the bend arc center. This is the same as a girder.

* bend angle is always a dependent parameter dependent on g and len.

* `NaN` is used instead of something like `missing` since `NaN` is considered a Float so can specify a parameter like `len_chord` as `Float64` instead of `Union{Float64,Missing}` which is not as clean and will slow down calculations.

* Have a "definitions" section with short definitions of different terms and a link to more detail? EG define upstream/downstream.

Note: Could also have defined parameters to be Union{Float64,Missing} but this possibly incurs a speed penalty (but this has not been tested).

* InitTwiss are just a suggestion for how to start tracking.

* Implementation note: Bookkeeping is element-by-element rather then parameter group by parameter group since 
the parameter groups are not necessarily independent. For example, the reference time will depend upon
the FloorParams if the lattice contains a flexible patch. 

* Using Strings for the keys of ele.pdict[] would have worked instead of Symbols. Using Symbols gives
a slightly cleaner look to the code.

* Before lattice expansion element parameter setting order is not important (except if a given parmeter
values is redefined).

* Discuss how tracking is used to calculate ref energy and time and how to override the standard calc.

* Magnetic multipoles: Specifying both normalized ("K") multipole and non-normalized ("B") values for a given order is not permitted. EG: "K2 = 0.3, B2 = 4".

* Multipoles: Before lattice expansion when defining an element: multipole value of a given order must be all integrated (Knl, Knsl, Bnl, Bnsl, Enl, Ensl) or not integrated (Kn, Kns, Bn, Bns, En, Ens). No mixing but can have one order integrated and another not. After lattice expansion, can switch from non-integrated to integrated  by setting an integrated value and vice versa. 

* Coding tip: Element group structures are not mutable by design to maximize tracking speed. This is a bit inconvenient when a structure needs to be modified. One way to handle this is using the @set macro. Another way is to convert a structure instance to a Dict, change the Dict, and then convert back (note: this is possible since the @kwdef macro was used to define the element group structures). Example: ...

* Some element groups are optional and may not be present in a given element. For example, LengthParams is required and BMultipoleParams and EMultipoleParams are optional.

* Online documentation: For element groups use REPL "?" and type in the name.

* Internally radians will be used for all parameters like RF phase, etc. This is in contrast to Fortran-Bmad which used radians/2pi for RF phase units.

* ele.name is an exception in that setting it will directly set ele.pdict[:name] bypassing the inbox.

* Lattice elements with the same name are independent.

* element variables defined externally to the lattice will remain after lattice expansion. 
To remove use kill_external_ele.

* Do not superimpose with reference ele and superimpose ele on different sides of a patch!
Getting the offset right can be tricky!

* Superposition of a zero length element with zero offset from the ref element will happen at the upstream end of the ref element (except for the beginning element).

* Superposition and Containers. Containers can be oriented (just like other elements) and contained lords can be oriented with respect to the containers. Bend elements are not allowed.

* lat.super_lord, lat.multipass_lord, lat.governor pointers.

* A multipass lord stores the list of slaves in .pdict[:slave] = Vector{Ele}. The slaves get a "!mpN" suffix where "N" is the pass index. The lord pointer is put in .pdict[:multipass_lord]

* Super lord/slaves store info similar to multipass except the slave uses .pdict[:super_lord] to point to the lord and this is a Vector{Ele}. Also slaves get a "!sN" for singleton slaves and "A!B!C..." name

* branch.pdict[:type] = LordBranch, TrackingBranch

* info function only lists element parameters that can be set.

* For ele_finder: Using Julia regex has limitations: 
    No element ranges. 

* Basic difference between controller and ramper is that rampers have a time dependence that comes from tracking rather than being dependent upon the variables associated with the element.

* Beamline expansion: species_ref, pc_ref, E_tot_ref may be stored in the Beamline.pdict or in begin_ele

* Always use absolute time tracking?

* Put lattice files in modules for namespace safety of exported element names.

* End element in a branch must be a marker.

* Document Ele.pdict[:private] used in keeping track of split drifts.
