Controller

[DavidSagan]

With Bmad, controllers are widely used in simulations of a wide range of machines at a number of laboratories This is due to the fact that what controllers simulate are basic building blocks for virtually all accelerators. While deferred expressions can be used in place of controllers, controllers add a level of organization and modularity that make them useful constructs. The ability to add documentation to a controller and the ease of being able to search and sort by controller name are features that deferred expressions lack.

Close #235

[mattsignorelli]

Just to continue the discussion in #235 here:
Deferred expressions are meant to embody physical dependencies such as power supplies. And specifying summation with them is no problem. My only concern is that having several different ways of specifying the same thing in the standard may be suboptimal. All that Controller achieves can currently be achieved using deferred expresions

[DavidSagan]

@mattsignorelli My experience is that in practice controllers can simplify machine control organization. For example, how would you handle the relative controller chromaticity example with deferred expressions? (actually I'm not sure deferred expressions can really handle this case.)

[mattsignorelli]

@mattsignorelli My experience is that in practice controllers can simplify machine control organization. For example, how would you handle the relative controller chromaticity example with deferred expressions? (actually I'm not sure deferred expressions can really handle this case.)

In SciBmad this would look like:

k2 = 0.33
command = 0
dk2 =  DefExpr(()->5.62*command + 0.02*command^2 )

S1 = Sextupole(Kn2=k2 + dk2)

I attached a file including the sextupole family knobs (which automatically keep chromaticity to +1 in both planes) that I am using now in the ESR.

Archive.zip

[DavidSagan]

@mattsignorelli My experience is that in practice controllers can simplify machine control organization. For example, how would you handle the relative controller chromaticity example with deferred expressions? (actually I'm not sure deferred expressions can really handle this case.)

In SciBmad this would look like:

k2 = 0.33
command = 0
dk2 =  DefExpr(()->5.62*command + 0.02*command^2 )

S1 = Sextupole(Kn2=k2 + dk2)

I attached a file including the sextupole family knobs (which automatically keep chromaticity to +1 in both planes) that I am using now in the ESR.

Archive.zip

First what you show acts differently from what the relative controller does. And how would you implement this in a PALS file (remember, PALS just defines expressions but applying them after the lattice is read in is up to the program. So the equivalent of S1 = Sextupole(Kn2=k2 + dk2) would not be in the PALS file).

[mattsignorelli]

First what you show acts differently from what the relative controller does.

Could you clarify the differences specifically? I must be misunderstanding your text in this PR.

And how would you implement this in a PALS file (remember, PALS just defines expressions but applying them after the lattice is read in is up to the program. So the equivalent of S1 = Sextupole(Kn2=k2 + dk2) would not be in the PALS file).

So PALS does not have deferred expressions?

[DavidSagan]

PALS does have deferred expressions. PALS defines what you could call the "initial lattice". Variations of parameters happens after the PALS file is read and this variation is not part of the PALS file. Controllers made parameter variation straight forward in a way that bare expressions do not. In your above example, the delta dk2 should be computed at the difference between the beginning value of command and the ending value. Also you only show control of one sextupole. How do you write this when there are N sextupoles to control?

[mattsignorelli]

PALS does have deferred expressions. PALS defines what you could call the "initial lattice". Variations of parameters happens after the PALS file is read and this variation is not part of the PALS file.

I think we might have disagreeing definitions of "deferred expressions". What I am referring to the deferred expression as defined in MAD-X (using :=) , MAD-NG, Xsuite, and SciBmad. The whole point is that you can change parameters and have their interdependencies hardwired in. If PALS does not support variation , then PALS does not have deferred expressions

[DavidSagan]

Currently, PALS is setup to define an initial lattice. Variation of parameters is left to the simulation program. There is no concept in PALS as to immediate evaluation vs. deferred evaluation. Essentially the program knows about all the equations in the PALS file and is free to vary any parameter that the User wants to vary.

[DavidSagan]

Note: Reference to the "delayed expression" definition will not be valid until #240 PR is merged.

[ax3l]

@DavidSagan I am just thinking through an implementation here:
Would variables here be allowed to reference or inherit another controller or element variable in it?

If we allow this (which seems natural in the existing PALS constructs we allow), we should define the precedence of evaluation (in #240 (comment))

[DavidSagan]

I'm not quite sure what you man by "Would variables here be allowed to reference or inherit another controller or element variable in it?" A controller can control the variables of another controller so there can be a hierarchy of controllers (loops are forbidden). The hierarchy can be determined by the parser and passed to the calling program. Evaluation is from the top down. I will add this info to the PR...

[DavidSagan]

I have add documentation on this. Note that, to keep things sane, controller expressions cannot contain lattice parameters.