deviation between optimizer results and subsequent tracking using these results
Posted: 19 May 2020, 11:20
Dear Michael,
I have an issue with the results from the optimization process: as you can see in the attached files, I defined two different types of &optimization_term, the problem exists with both.
First (folder “sene”):
If I use
The algorithm terminates with an optimization function value of 0, so the goal is achieved:
However, when I perform a subsequent tracking with these solutions (using the created optimization.new file), there are significantly greater deviations, far away from what I have set as goals. You can find the following results in the track_solution.cen file:
Second (folder “sqr”):
If I use
The algorithm terminates with the following values:
so that the biggest absolute deviation should be (3.762752921933874e-24)^0.5 < 2e-12 but again, tracking with the results (from optimization.new file) and checking track_solution.cen one gets:
Why do the results of the subsequent tracking using the optimum values of variables yield from the optimization algorithm not yield to the same deviations like the final values of the terms of the optimization algorithm? Or am I doing something wrong?
I checked with the elegant versions 2020.2.0 and 34.3.1 on Windows 10 and version 34.4.1 on Debian 9. I used elegant and Pelegant. The problem is everywhere.
For the above mentioned results, I use 100 particles, so you can reproduce quickly. I used 5000 particles before and the problem is there, too.
Don't be surprised about the small transverse extent of the bunches; in the first step I'm only interested in the longitudinal behavior so I chose smalls transverse beam values to ignore transverse focusing initially. Is there a smarter way using &bunched_beam to choose x = y = x '= y' = 0 for all electrons instead of choosing tiny values for emittance and beta (zero is forbidden)?
Many thanks in advance and best regards,
Felix
I have an issue with the results from the optimization process: as you can see in the attached files, I defined two different types of &optimization_term, the problem exists with both.
First (folder “sene”):
If I use
Code: Select all
&optimization_term term="M18#1.pCentral 48.9237795889796 1e-9 sene", weight=1.0 &end ! 25 MeV/c
&optimization_term term="M28#1.pCentral 88.0628032601632 1e-9 sene", weight=1.0 &end ! 45 MeV/c
&optimization_term term="M38#1.pCentral 48.9237795889796 1e-9 sene", weight=1.0 &end ! 25 MeV/c
&optimization_term term="M48#1.pCentral 9.78475591779592 1e-9 sene", weight=1.0 &end ! 5 MeV/c
Code: Select all
M18#1.pCentral 48.9237795889796 1e-9 sene: 0.000000000000000e+00
M28#1.pCentral 88.0628032601632 1e-9 sene: 0.000000000000000e+00
M38#1.pCentral 48.9237795889796 1e-9 sene: 0.000000000000000e+00
M48#1.pCentral 9.78475591779592 1e-9 sene: 0.000000000000000e+00
Code: Select all
pCentral @ M18 = 49.119348876298325 (that is roughly 2e-1 away from the goal)
pCentral @ M28 = 88.0681916166654 (that is roughly 5e-3 away from the goal)
pCentral @ M38 = 48.77366771482586 (that is roughly 2e-1 away from the goal)
pCentral @ M48 = 9.786591451458106 (that is roughly 2e-3 away from the goal)
If I use
Code: Select all
&optimization_term term="M18#1.pCentral 48.9237795889796 - sqr", weight=1.0 &end ! 25 MeV/c
&optimization_term term="M28#1.pCentral 88.0628032601632 - sqr", weight=1.0 &end ! 45 MeV/c
&optimization_term term="M38#1.pCentral 48.9237795889796 - sqr", weight=1.0 &end ! 25 MeV/c
&optimization_term term="M48#1.pCentral 9.78475591779592 - sqr", weight=1.0 &end ! 5 MeV/c
Code: Select all
M18#1.pCentral 48.9237795889796 - sqr: 1.018021842744095e-24
M28#1.pCentral 88.0628032601632 - sqr: 3.005799862607242e-24
M38#1.pCentral 48.9237795889796 - sqr: 3.762752921933874e-24
M48#1.pCentral 9.78475591779592 - sqr: 7.005400382724673e-26
Code: Select all
pCentral @ M18 = 49.11934888262161 (that is roughly 2e-1 away from the goal)
pCentral @ M28 = 88.06819161743 (that is roughly 5e-3 away from the goal)
pCentral @ M38 = 48.77366770995617 (that is roughly 2e-1 away from the goal)
pCentral @ M48 = 9.786591449261289 (that is roughly 2e-3 away from the goal)
I checked with the elegant versions 2020.2.0 and 34.3.1 on Windows 10 and version 34.4.1 on Debian 9. I used elegant and Pelegant. The problem is everywhere.
For the above mentioned results, I use 100 particles, so you can reproduce quickly. I used 5000 particles before and the problem is there, too.
Don't be surprised about the small transverse extent of the bunches; in the first step I'm only interested in the longitudinal behavior so I chose smalls transverse beam values to ignore transverse focusing initially. Is there a smarter way using &bunched_beam to choose x = y = x '= y' = 0 for all electrons instead of choosing tiny values for emittance and beta (zero is forbidden)?
Many thanks in advance and best regards,
Felix