Optimizer ends prematurely

[foshea]

I am trying to optimize a beam line that is split by a dipole that can be either on or off. I'm working with the Twiss parameters, so I pull the Twiss parameters from just before the dipole and paste the straight beam line on to the end of the bent beam line. I have attached all the files necessary to recreate my problem. I have two problems that I think are related, but I'm not sure.

1) TWISS elements cannot be used as covariables when the output_at_each_step flag of twiss_output is nonzero, elegant throws an UNKNOWN TOKEN error.
Further details can be found in this topic: viewtopic.php?f=9&t=1053
This bug can be replicated by un-commenting the line that contains output_at_each_step in the attached input.ele file.

2) The optimizer ends prematurely.
For the attached files, the value of the optimizer stops at approximately 2400, while the goal is zero.
The output.fin file shows that optimizationFunction is converging but optimized shows up as 1 for the last step, even though the optimization criteria is clearly unmet. So I don't think the optimizer is stuck in a local minimum. The total number of steps is a small fraction of the allowed number, so I don't think the optimizer has reached its limit there either.

I have tried fiddling with some of the flags, but nothing seems to help. If I manually compute a set of parameters that is close to what I want, the optimizer will sometimes, but not always, reach zero. However, the output to the screen will show that not all of the terms converged.

My suspicion is that the Twiss parameters are not being updated at each step and that the optimizer is doing something strange with stored values for the Twiss values, maybe updating them at each pass (as opposed to each step)? But clearly, I cannot have elegant output the Twiss parameters at each step because that does not allow optimization to proceed at all.

Any guidance would be appreciated.

[michael_borland]

I was able to get this to work with a few changes: I fixed a typo on line 58 ("end" -> "&end"). I used the parallel hybrid simplex optimizer, which provides better convergence in challenging cases. I also eliminated some unnecessary output results in the run_setup command. Finally, after optimization, I evaluate the Twiss parameters for the two branches separately. It seems to work. Please see attached.

--Michael

[michael_borland]

By the way, to run the parallel optimzer, use Pelegant, e.g.,
mpiexec -np 18 Pelegant input.ele

--Michael

[foshea]

Thanks for the help moving on to the parallel optimizer.

I've noticed something I did not expect about the solution. The optimized beam line has two instances of the MARKER MARK-MDLS.01, one comes just before TM1 (a TWISS object) and the other just after. To reset the twiss parameters at TM1 I use the following co-variable commands:

Code: Select all

&optimization_covariable name=TM1, item=betax, equation="MARK-MDLS.01#1.betax" &end
&optimization_covariable name=TM1, item=alphax, equation="MARK-MDLS.01#1.alphax" &end
&optimization_covariable name=TM1, item=betay, equation="MARK-MDLS.01#1.betay" &end
&optimization_covariable name=TM1, item=alphay, equation="MARK-MDLS.01#1.alphay" &end

The optimization works if I fiddle with some of the parameters (I think because I don't have 18 processors). However, when I look at run2, the twiss parameters at MARK-MDLS.01#1 and TM1 don't match. Here is a small part of run2.twi showing s,betax,alphax,betay,alphay,ElementName

Code: Select all

 2.704000000000000e+00  3.813952121115502e+00 -2.999981525928532e+00  8.281599433439832e+00  3.750694470310970e+00 MDL-D.07
 2.704000000000000e+00  3.813952121115502e+00 -2.999981525928532e+00  8.281599433439832e+00  3.750694470310970e+00 MARK-MDLS.01
 2.704000000000000e+00  3.819507331991306e+00 -3.007848501205935e+00  8.296778684367091e+00  3.751395082853180e+00 TM1
 2.704000000000000e+00  3.819507331991306e+00 -3.007848501205935e+00  8.296778684367091e+00  3.751395082853180e+00 MARK-MDLS.01

If I eliminate the second instance of MARK-MDLS.01 and rerun the optimization, the twiss parameters at the first MARK-MDLS.01 and TM1 now match:

Code: Select all

 2.704000000000000e+00  7.746094261081707e+00 -6.724953162396224e+00  1.000573163357558e+01  4.610378808409145e+00 MDL-D.07
 2.704000000000000e+00  7.746094261081707e+00 -6.724953162396224e+00  1.000573163357558e+01  4.610378808409145e+00 MARK-MDLS.01
 2.704000000000000e+00  7.746094261081707e+00 -6.724953162396224e+00  1.000573163357558e+01  4.610378808409145e+00 TM1
 3.924766362093652e+00  3.305851090465491e+01 -1.400990440704206e+01  2.064126347050101e+00  1.895047236346367e+00 MDL-D.08

The values are quite different as well. I tried to eliminate the second MARK-MDLS.01 in the files I originally posted and it doesn't help with the original convergence problem. So I guess these issues are unrelated.

[michael_borland]

Sounds like there may be a bug. I'll look into it.

I wouldn't expect exact convergence in this case, since there's a bit of a chicken-and-egg problem. ELEGANT asserts the values of the optimization variables and covariables, then computes the updated Twiss parameters. So the asserted values for the TWISS element are from the previous computation of the Twiss parameters. If things converge well, this should eventually not matter. However, it is possible that it might introduce slow convergence, which might explain the need to use the parallel optimizer.

--Michael