Matching problems (R36,R46 and R56)

Moderators: cyao, michael_borland

Post Reply
MDP
Posts: 25
Joined: 02 Jul 2010, 07:33
Location: DESY Hamburg/Germany

Matching problems (R36,R46 and R56)

Post by MDP » 25 Nov 2013, 04:04

Dear elegant users and experts,

I’m optimizing the beam line layout of an extraction section where an electron beam can be distributed at the end of a linac to two FEL beam lines. A solution that fulfills all constraints was found before; however, I’m trying to improve the layout to reduce chromatic aberrations. I tell you that to point out that the optimization was running before without any problems…

Most recently it happend that the optimization itself looked very good and it looked like that all constraints are fulfilled. But if I check the parameters is the dumped files, I have to note that this is not the case… This happens especially for the transfer matrix elements R36, R46 and R56.

e.g. when I set the following optimization terms (the related files are attached):

&optimization_term term = " R36 0 1e-6 sene " &end
&optimization_term term = " R46 0 1e-6 sene " &end
&optimization_term term = " R56 0 1e-5 sene " &end

and run the optimization, elegant prompts on the screen that all constraints are fulfilled:

R36 0 1e-5 sene : 0.000000000000000e+00
R46 0 1e-5 sene : 0.000000000000000e+00
R56 0 1e-6 sene : 0.000000000000000e+00

However, the in the file optimization.mat containing all transfer matrix elements one can find:

ElementName --------- R16 ----------- R26 ------------- R36 ------------- R46 -------------- R56
-------------------------- m/1 --------- rad/1 ------------ m/1 ------------ rad/1 ------------ m/1
--------------------------------------------------------------------------------------------------------------------
MEND ---------- 1.345624e-05 | 6.579924e-06 | -6.166394e-03 | -2.386191e-03 | -1.636987e-04

Thus, the final values for the R36, R46 and R56 are larger than expected.

I’m confused about these problems and I tried to find the cause but I was not able to find a solution. I rewrote both files and I compared them with the old ones (which worked fine) but I could not find crucial differences.

My question is now if any of you can find the trouble maker or if you could give me a hint what I could do next.

Thank you in advance!
Matthias

michael_borland
Posts: 1933
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: Matching problems (R36,R46 and R56)

Post by michael_borland » 25 Nov 2013, 04:27

Matthais,

This shouldn't happen, of course. Can you post the files so I can run it myself?

--Michael

MDP
Posts: 25
Joined: 02 Jul 2010, 07:33
Location: DESY Hamburg/Germany

Re: Matching problems (R36,R46 and R56)

Post by MDP » 25 Nov 2013, 04:46

Hi Michael,

Thanks for your answer and sorry that I forgot to attach the files...

Best regards,
Matthias
Attachments
optimization.lte
(43.43 KiB) Downloaded 363 times
optimization.ele
(5.56 KiB) Downloaded 378 times

michael_borland
Posts: 1933
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: Matching problems (R36,R46 and R56)

Post by michael_borland » 25 Nov 2013, 04:58

Matthais,

The Rij elements shown by elegant are always computed about the trajectory or closed orbit, not the ideal x=y=0 position. So the problem is that in the second step, you set default_order=3, whereas in the first step you had default_order=1. Normally, this would be ok but you also have a non-zero trajectory. The feed-down of the higher-order matrices into the lower order for the non-zero trajectory results in changes in the Ri6 matrix elements.

You can set default_order=3 in the optimization step so elegant will include the feed-down in the optimization. Of course, it will take longer and may not even have a solution. Note that elegant doesn't have a third order matrix for dipoles, so you might just set default_order=2.

--Michael

MDP
Posts: 25
Joined: 02 Jul 2010, 07:33
Location: DESY Hamburg/Germany

Re: Matching problems (R36,R46 and R56)

Post by MDP » 26 Nov 2013, 08:36

Hi Michael,

thanks for your help! I will now optimize with first order matrices as far as possible and switch then to second order for the optimization and for the final elegant run.

Best regards,
Matthias

Post Reply