Hi Everybody!
I'm trying to optimize a system of bends and quadrupoles. I want to use symmetry to optimize the lattice. An example is attached in zipped format, which contains an ini file, a dat file, and a cal file.
To enforce the symmetry, I have linked the elements in the way described by the manual, by giving them "the same matching element number n." This works for every element in the lattice but drift D4, which appears to be ignored. Since the cal file doesn't contain the optimized length for D4, I assume it is totally ignored by the optimizer. If I change the preceding MATCH_FAM_LENGTH command to "MATCH_FAM_LENGTH 4 7", i.e. I give it a separate element number, D4 appears in the optimizer. In the below image, element[10], which is D4, does not appear.
A different problem I am having with optimization is enforcing the SET_SIZE_MAX optimization constraint. The manual says that "[t]he sizes are the effective beam sizes (rms*sqrt(5) for bunched beam or rms*sqrt(4) for CW beam)". I want to limit the 5*rms beam size to 20 mm, so I calculate the size I should enter here is 9 mm. However, the optimizer shows that values smaller than 9 mm are violating the optimization term. In the above image, all of the beam sizes are smaller than the constraint, yet the beam size max criterion is in the 1e2 range. If I use 20 mm in the SET_SIZE_MAX command, the optimizer happily lets the beam be 8.94 mm. I'd guess that criterion is being computed with 5*rms, instead of sqrt(5)*rms, but I'm not sure.
Thanks in advance for any help,
Finn
Optimization appears to ignore some linked terms and miscalculate the beam size
Optimization appears to ignore some linked terms and miscalculate the beam size
 Attachments

 dba.zip
 (2.53 KiB) Downloaded 71 times
Re: Optimization appears to ignore some linked terms and miscalculate the beam size
Dear foshea,
The D4 drift does not appear on the optimisation display because it is linked. So what's the point. But if you look in the "Data" tabsheet after the optimisation, you can see its value equal to D3. Another way to check this, is to look the new final *.dat file created at the end of the calculation in the "calculation directory", "output" for you.
The set_size_max command does not set a size but tries to limit to a size below the requested value which would be an upper limit, but there is no lower limit. This criterion is not a hard limit, if you look at its formula, you will understand that the objective is to try not to exceed the max size and if it is lower the value of the criterion becomes very quickly negligible.
I say try, because obviously it is not always possible. It depends on the configuration of the line and other required criteria such as achromaticity. Not everything is possible at the same time.
Moreover, your first order is useless because no element is adjusted upstream.
I confirm that the beam is defined as sqrt(4) or sqrt(5) time rms size.
Perhaps you should use SET_SIZE command instead.
Regards,
Didier
The D4 drift does not appear on the optimisation display because it is linked. So what's the point. But if you look in the "Data" tabsheet after the optimisation, you can see its value equal to D3. Another way to check this, is to look the new final *.dat file created at the end of the calculation in the "calculation directory", "output" for you.
The set_size_max command does not set a size but tries to limit to a size below the requested value which would be an upper limit, but there is no lower limit. This criterion is not a hard limit, if you look at its formula, you will understand that the objective is to try not to exceed the max size and if it is lower the value of the criterion becomes very quickly negligible.
I say try, because obviously it is not always possible. It depends on the configuration of the line and other required criteria such as achromaticity. Not everything is possible at the same time.
Moreover, your first order is useless because no element is adjusted upstream.
I confirm that the beam is defined as sqrt(4) or sqrt(5) time rms size.
Perhaps you should use SET_SIZE command instead.
Regards,
Didier
Re: Optimization appears to ignore some linked terms and miscalculate the beam size
Hi Didier,
Now I am confused about why D4 doesn't show up in the optimization screen, but all of the other linked elements do?
As to the SET_SIZE_MAX issue. Why is it "punishing" values below the allowed maximum so strongly? There are two SET_SIZE_MAX commands given, all with a maximum allowed value of 9 mm. The values the optimizer finds are 5.02, 6,51, 4.93, and 6.29 mm. All of these values are less than 9 mm, so I would think that "beam size max criterion" would be zero (or some really small number). But it is not, it is 1.67e2. That is the largest optimization criterion listed in that image, but it is the only goal the optimizer says it has actually achieved. That seems wrong to me.
Finn
P.S. Yeah, the first SET_SIZE_MAX isn't under this optimizer's control, but I made this example by pulling from a larger simulation and I wanted to keep as many of the features as possible.
Now I am confused about why D4 doesn't show up in the optimization screen, but all of the other linked elements do?
As to the SET_SIZE_MAX issue. Why is it "punishing" values below the allowed maximum so strongly? There are two SET_SIZE_MAX commands given, all with a maximum allowed value of 9 mm. The values the optimizer finds are 5.02, 6,51, 4.93, and 6.29 mm. All of these values are less than 9 mm, so I would think that "beam size max criterion" would be zero (or some really small number). But it is not, it is 1.67e2. That is the largest optimization criterion listed in that image, but it is the only goal the optimizer says it has actually achieved. That seems wrong to me.
Finn
P.S. Yeah, the first SET_SIZE_MAX isn't under this optimizer's control, but I made this example by pulling from a larger simulation and I wanted to keep as many of the features as possible.
Re: Optimization appears to ignore some linked terms and miscalculate the beam size
Hi,
First of all, as you have noticed, I found a problem with the display and saving of the linked value. This problem is corrected in the new version of TraceWin: 2.1.6.2
About the penalty function, I redo the calculation using your result and I confirm that the result is good. I understand that you are hoping for a value close to 0, but the function must be a continuous function otherwise it will not converge properly. You can weight it by using the first parameter 'k' or even by increasing '9'. You have to adjust its parameters according to the final results you want.
Regards,
Didier
First of all, as you have noticed, I found a problem with the display and saving of the linked value. This problem is corrected in the new version of TraceWin: 2.1.6.2
About the penalty function, I redo the calculation using your result and I confirm that the result is good. I understand that you are hoping for a value close to 0, but the function must be a continuous function otherwise it will not converge properly. You can weight it by using the first parameter 'k' or even by increasing '9'. You have to adjust its parameters according to the final results you want.
Regards,
Didier