deviation between optimizer results and subsequent tracking using these results

[Ikpfelix]

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

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

The algorithm terminates with an optimization function value of 0, so the goal is achieved:

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

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:

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)

Second (folder “sqr”):
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

The algorithm terminates with the following values:

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

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:

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)

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

[michael_borland]

Felix,

Sorry for the long delay. The problem here is that by default elegant fiducializes time-dependent elements to the first beam it sees. The time of flight between the RFTMEZ0 elements is determined by the energy profile. In the first step of the optimization, elegant records the arrival time at each time-dependent element and uses that to determine the meaning of the phase values. In the evaluation step, the time of flight is different because of the new phase values.

What elegant should do in the optimization is redefine the time references for each step. However, this isn't working for RFTMEZ0. I'll fix that in the next release. As a workaround, you can set fiducial="t,light" on the RFTMEZ0 elements, so elegant will fiducialize to a light-speed particle. If you do that, the evaluation step should agree very well with the final optimization result.

--Michael

[Ikpfelix]

Dear Michael,

thanks for your response and the explanation.

I tried your suggestion with FIDUCIAL="t,light" and yes, in that case the subsequent tracking satisfies the conditions from the optimization. To be on the safe side about the parameter "FIDUCIAL": does the case FIDUCIAL="t,light" mean, that the first cavity "starts to swing with the predefined phase", when a particle with speed of light would arrive the cavity?

Just to be sure to not misunderstand the fiducialization and timestamp effect in elegant: In my initial presented case (without FIDUCIAL="t,light"), I used eight cavities with eight different PHASE_REFERENCE values. In that case, the arrival time at cavity #2 changes as a function of the phase at cavity #1 since the particle velocity differs (self-evident) and therefore the global time at which cavity #2 "starts to swing with the predefined phase" (=arrival time of the electron bunch median at cavity #2) changes, and so on for the other cavities, correct?

In the first step of the optimization, elegant records the arrival time at each time-dependent element

But what if all cavities have the same PHASE_REFERENCE value? Do they not all start to swing at the same time (with their individual predefined phases) as soon as the electron bunch reaches the first cavity? Regardless of the phase of the first cavity? I think that is a tricky point. I.e., as long as one doesn't have time-influencing changes upstream the first cavity, one shouldn't see a difference, right?
So I tested another case with no specification for FIDUCIAL and all cavities have PHASE_REFERENCE=1. In that case I got the same big deviations like in my initial problem with eight different PHASE_REFERENCE values. But I did not expect that, since the issue you described ("elegant records the arrival time at each time-dependent element") should not occur now (if my described understanding is correct). Or is there still a function depending on the particle velocity and/or phase of cavity #1, even if all cavities have PHASE_REFERENCE=1 ? Is this another bug? I am not sure whether I understood the fiducialization/PHASE_REFERENCE function correctly.

Regarding this: does it make a difference to use the same time-dependent element several times or to use different defined elements with the same PHASE_REFERENCE, for example:

Code: Select all

A1SC01: RFTMEZ0, PHASE_REFERENCE=1, ...
beamline: line=(2*A1SC01)

vs

Code: Select all

A1SC01: RFTMEZ0, PHASE_REFERENCE=1, ...
A1SC02: RFTMEZ0, PHASE_REFERENCE=1, ...
beamline: line=(A1SC01,A1SC02)

?

My goal is to avoid a reference to speed of light particles. I am using RFTMEZ0 instead of RFCA in order to get the full influence of phase slippage since we have electrons with 5 MeV/c. When I use FIDUCIAL="t,light", do I still get a proper solution and my only problem then is to recalculate the phases from speed of light to the "slow" electrons, or is the phase slippage in that case not included?

Nevertheless, fixing the bug is the nicest solution, because then it will be easier to transfer the obtained optimal values to the real machine. Thanks in advance for fixing it.

-----------------------------------------------------------------------------------

There are a few more issues concerning FIDUCIAL:

1. I can imagine the difference between FIDUCIAL="t,min" and FIDUCIAL="p,min".
   But what is the difference between FIDUCIAL="t,first" and FIDUCIAL="p,first" or between FIDUCIAL="t,light" and FIDUCIAL="p,light"? And what is "first"? The first particle arriving or the first particle in the .bun file?
2. I tried your suggestion and tried all FIDUCIAL options listed in the manual. Using elegant, all of the options {median|min|max|ave|first|light} are working fine. But using Pelegant, I found two problems (regardless of the number of threads (hereinafter for n=4)). I tried with
   Windows 10 Education, elegant 2020.2.0, Microsoft MPI 9.0.12497.11
   and
   Debian GNU/Linux 9, elegant 34.4.1, HYDRA 3.2:
   1. Using FIDUCIAL="t,light" I get the error message

      Code: Select all

      Terminated by SIGSEGVProgram trace-back:

      And the console is frozen. Aborting with Ctrl+C yields to the following message on Windows

      Code: Select all

      mpiexec aborting job...
      job aborted:
      [ranks] message
      [0] process exited without calling finalize
      [1-3] terminated
      ---- error analysis -----
      [0] on DESKTOP-EGD1H4L
      Pelegant ended prematurely and may have crashed. exit code 0
      ---- error analysis -----

      and on Linux:

      Code: Select all

      ^C[mpiexec@graka] Sending Ctrl-C to processes as requested
      [mpiexec@graka] Press Ctrl-C again to force abort
      simplexMin abort requested
      simplexMin abort requested
      simplexMin abort requested
      simplexMin abort requested
      ^CCtrl-C caught... cleaning up processes
      [proxy:0:0@graka] HYD_pmcd_pmip_control_cmd_cb (pm/pmiserv/pmip_cb.c:885): assert (!closed) failed
      [proxy:0:0@graka] HYDT_dmxu_poll_wait_for_event (tools/demux/demux_poll.c:76): callback returned error status
      [proxy:0:0@graka] main (pm/pmiserv/pmip.c:206): demux engine error waiting for event
      [mpiexec@graka] HYDT_bscu_wait_for_completion (tools/bootstrap/utils/bscu_wait.c:76): one of the processes terminated badly; aborting
      [mpiexec@graka] HYDT_bsci_wait_for_completion (tools/bootstrap/src/bsci_wait.c:23): launcher returned error waiting for completion
      [mpiexec@graka] HYD_pmci_wait_for_completion (pm/pmiserv/pmiserv_pmci.c:218): launcher returned error waiting for completion
      [mpiexec@graka] main (ui/mpich/mpiexec.c:344): process manager error waiting for completion

      I am not sure if the error message are useful for you, but I usually see other messages when I abort Pelegant with Ctrl+C.
   2. Using FIDUCIAL="t,median" didn’t work. On Windows I got only

      Code: Select all

      job aborted:
      [ranks] message
      [0] application aborted
      aborting MPI_COMM_WORLD (comm=0x44000000), error 2, comm rank 0
      [1] application aborted
      aborting MPI_COMM_WORLD (comm=0x44000000), error 2, comm rank 1
      [2] application aborted
      aborting MPI_COMM_WORLD (comm=0x44000000), error 2, comm rank 2
      [3] application aborted
      aborting MPI_COMM_WORLD (comm=0x44000000), error 2, comm rank 3
      ---- error analysis -----
      [0-3] on DESKTOP-EGD1H4L
      Pelegant aborted the job. abort code 2
      ---- error analysis -----

      and ok on Linux I got the warning that "median" is not available for Pelegant:

      Code: Select all

      The median fiducial mode is not available in Pelegant.
      application called MPI_Abort(MPI_COMM_WORLD, 2) - process 0
      application called MPI_Abort(MPI_COMM_WORLD, 2) - process 1
      application called MPI_Abort(MPI_COMM_WORLD, 2) - process 2
      application called MPI_Abort(MPI_COMM_WORLD, 2) - process 3

      But, if it is not available, what is the default setting for Pelegant if I do not specify FIDUCIAL, since "median" should be default according to the manual?

Please excuse my amount of questions. Things that once seemed clear to me suddenly raise big questions.

Thanks in advance and best regards,
Felix