New matching

[swhite2401]

@lfarv, I start here a discussion to collect remarks on the new matching functions

[swhite2401]

First remark: matching mu is really not user friendly, in fact for the moment the only way I managed to do it in the new matching is by creating a user function.

The previous matching had been improve iteratively with several functionalities:
-use_integer: select whether to use or not the integer part, this prevent calculating optics at all refpts and significantly speeds up the calculation
-allow for matching in units in units of 2*pi instead of phase

Second remark: when one defines a refpts that is not found observable returns None and matching proceed, in this case I would raise an AtError: "Refpts not defined for ring" or something similar

[lfarv]

@swhite2401 : good idea to group all the requests before defining a new version.

phase advance matching

• integer part: the LocalOpticsObservable has a all_points keyword, which indeed significantly changes the computation time. At the moment it is forced to True when asking for mu. From the documentation:

  all_points: Compute the local optics at all elements. This avoids discontinuities in phase advances. This is automatically set for the 'mu' parameter, but may need to be specified for user-defined evaluation functions using the phase advance.

  We can remove the special treatment of mu: all_points is False by default. This is dangerous: you can never know where the phase advance jumps by 2 $\pi$, but why not.

  Or change the default: all_points would default to False, except for the mu parameter where it defaults to True. This is safer, the user has to explicitly set all_points to False if he accepts phase jumps.

• units of 2*pi: add a keyword in LocalOpticsObservable? Or create a new parameter name meaning $\frac{\mu}{2\pi}$?

• user function: are you matching the phase advance at a given location or the difference of phase advance between 2 points ? Then have a look at this, it's quite simple. Though we can look for another solution…

[swhite2401]

The most use case is to fit the fractional part, it is very rare that one would change integer.

My proposal would then be to create additional parameters:
-keep mu as is, compute at all refpts and include integer part
-add muf, compute only at needed refpts and match only the fractional part
-mu2pi, and muf2pi would allow matching in units of 2pi (which is what one would naturally do)

all_points would be set to True only if mu or mu2pi are used for matching

I was matching the phase at a given point in units of 2pi, but there may be a bug there either in the matching or in my definition because x and y plane were returning the same value. So in the end I had to write separate x and y functions.