Location insensitive of the MALIGN element
Moderators: michael_borland, soliday
Location insensitive of the MALIGN element
Hi Michael,
I use MALIGN element to search for the maximum stable offsets. However, no matter where I put it, it displaces the coordinates as if it is at the beginning of the beamline. In other words, I always get the same dynamic aperture even if I move that element along the beamline.
Weiming
I use MALIGN element to search for the maximum stable offsets. However, no matter where I put it, it displaces the coordinates as if it is at the beginning of the beamline. In other words, I always get the same dynamic aperture even if I move that element along the beamline.
Weiming
-
- Posts: 1933
- Joined: 19 May 2008, 09:33
- Location: Argonne National Laboratory
- Contact:
Re: Location insensitive of the MALIGN element
Weiming,
That is very strange. Can you post some files that show the effect, or send them to me by email?
Thanks.
--Michael
That is very strange. Can you post some files that show the effect, or send them to me by email?
Thanks.
--Michael
Re: Location insensitive of the MALIGN element
Was this topic resolved ?
I have a question along the same line. I have a layout where a quadrupole is rotated in the horizontal plane by 10 deg. I simulate
it by entering the beam at an angle of opposite sign with MALIGN. I was expecting to have to restore the trajectory by a MALIGN of opposite sign at the end. It does'nt appear to be so. The MALIGN only seems to apply to the next element, as follows (note my non-active original lines).
Mis1R: MALIGN,DXP=0.1745329252
!Mis2R: MALIGN,DXP=-0.1745329252
yqdrnorot: quad,L="lyquad", K1="YQc largeQcon * kpeak *",FFRINGE ="lyquad lypeak - lyquad /" ,FRINGE_TYPE="INSET", ORDER=3
!yqdr: line=(Mis1R,yqdrnorot,Mis2R)
yqdr: line=(Mis1R,yqdrnorot)
Thanks, cheers, Max
I have a question along the same line. I have a layout where a quadrupole is rotated in the horizontal plane by 10 deg. I simulate
it by entering the beam at an angle of opposite sign with MALIGN. I was expecting to have to restore the trajectory by a MALIGN of opposite sign at the end. It does'nt appear to be so. The MALIGN only seems to apply to the next element, as follows (note my non-active original lines).
Mis1R: MALIGN,DXP=0.1745329252
!Mis2R: MALIGN,DXP=-0.1745329252
yqdrnorot: quad,L="lyquad", K1="YQc largeQcon * kpeak *",FFRINGE ="lyquad lypeak - lyquad /" ,FRINGE_TYPE="INSET", ORDER=3
!yqdr: line=(Mis1R,yqdrnorot,Mis2R)
yqdr: line=(Mis1R,yqdrnorot)
Thanks, cheers, Max
Re: Location insensitive of the MALIGN element
Max, I still see that problem mentioned above. However, yours is different. It won't completely restore the orbit if you use two MALIGN element as described in your message. You would get a displacement at the end due to the misalignment angle. You will need to correct that as following:
MA1: dxp=theta
MA2: dxp=-theta,dx = -theta*L
where L is the distance between MA1 and MA2. But this would be a good test of the original problem.
Weiming
MA1: dxp=theta
MA2: dxp=-theta,dx = -theta*L
where L is the distance between MA1 and MA2. But this would be a good test of the original problem.
Weiming
-
- Posts: 1933
- Joined: 19 May 2008, 09:33
- Location: Argonne National Laboratory
- Contact:
Re: Location insensitive of the MALIGN element
Here are some files that involve several malign elements. If you run
% elegant run.ele
% sddsprintout -column=ElementName -column=s -column=Cx* run.cen
ElementName s Cx Cxp
m m
----------------------------------------------------------
_BEG_ 0.000000e+00 0.000000e+00 0.000000e+00
MAL1 0.000000e+00 0.000000e+00 -1.000000e-03
D1 1.000000e+00 -1.000000e-03 -1.000000e-03
MAL2 1.000000e+00 -1.000000e-03 1.000000e-03
D1 2.000000e+00 0.000000e+00 1.000000e-03
MAL1 2.000000e+00 0.000000e+00 0.000000e+00
As you can see, the trajectory is kicked by each MALIGN element.
I think this shows that this much-maligned (pun intended) feature of elegant is working correctly.
--Michael
% elegant run.ele
% sddsprintout -column=ElementName -column=s -column=Cx* run.cen
ElementName s Cx Cxp
m m
----------------------------------------------------------
_BEG_ 0.000000e+00 0.000000e+00 0.000000e+00
MAL1 0.000000e+00 0.000000e+00 -1.000000e-03
D1 1.000000e+00 -1.000000e-03 -1.000000e-03
MAL2 1.000000e+00 -1.000000e-03 1.000000e-03
D1 2.000000e+00 0.000000e+00 1.000000e-03
MAL1 2.000000e+00 0.000000e+00 0.000000e+00
As you can see, the trajectory is kicked by each MALIGN element.
I think this shows that this much-maligned (pun intended) feature of elegant is working correctly.
--Michael
- Attachments
-
- run.ele
- (152 Bytes) Downloaded 629 times
-
- lattice.lte
- (93 Bytes) Downloaded 652 times
Re: Location insensitive of the MALIGN element
Thank you Michael and Weimin,
I did as you suggested and it works.
Another question: is there an easy way to transfer closed orbit data (rms or maximum value) into the .FIN file so that
I can use "optimize" (I only have one corrector for a special application) instead of the global closed orbit correction instruction ?
Thanks, cheers, Max
I did as you suggested and it works.
Another question: is there an easy way to transfer closed orbit data (rms or maximum value) into the .FIN file so that
I can use "optimize" (I only have one corrector for a special application) instead of the global closed orbit correction instruction ?
Thanks, cheers, Max
-
- Posts: 1933
- Joined: 19 May 2008, 09:33
- Location: Argonne National Laboratory
- Contact:
Re: Location insensitive of the MALIGN element
Max,
I think you want to fit the trajectory at an interior point using optimization. To do this, you need to insert a MARK element at the fit location, with FITPOINT=1, as in
M1: MARK,FITPOINT=1
BL: line=(...,M1,...)
In your optimization terms, you then use M1#1.Cx for the x centroid, etc. If you have multiple instances of the same MARK element in the beamline, use M1#1, M1#2, etc., Look here for more details.
--Michael
I think you want to fit the trajectory at an interior point using optimization. To do this, you need to insert a MARK element at the fit location, with FITPOINT=1, as in
M1: MARK,FITPOINT=1
BL: line=(...,M1,...)
In your optimization terms, you then use M1#1.Cx for the x centroid, etc. If you have multiple instances of the same MARK element in the beamline, use M1#1, M1#2, etc., Look here for more details.
--Michael
Re: Location insensitive of the MALIGN element
I checked my original problem. It occurred while I use the command find_aperture. In the lte file I defined two beam lines:
ring1 = (MA1,beamline1, beamline2)
ring2 = (beamline1,MA1,beamline2)
and I searched for dynamic aperture for both beam-lines and I was expecting to get different dynamic apertures since the beta functions are different at MA1 in two cases. However,
find_aperture always outputs dynamic aperture at the beginning. I checked the manual, apparently the default setting is to find aperture at the beginning of the beam-line. It never asks for a misalignment element.
Therefore this was a wrong assumption of mine, not a bug of elegant.
Regards,
Weiming
ring1 = (MA1,beamline1, beamline2)
ring2 = (beamline1,MA1,beamline2)
and I searched for dynamic aperture for both beam-lines and I was expecting to get different dynamic apertures since the beta functions are different at MA1 in two cases. However,
find_aperture always outputs dynamic aperture at the beginning. I checked the manual, apparently the default setting is to find aperture at the beginning of the beam-line. It never asks for a misalignment element.
Therefore this was a wrong assumption of mine, not a bug of elegant.
Regards,
Weiming
Re: Location insensitive of the MALIGN element
Michael,
many thanks for the useful information. Actually, I meant to optimize the closed orbit rather than the trajectory.
What I meant was: I know that .FIN (where the parameters reside that are used by "optimize") carries the trajectory data. Is there an easy way to
carry the closed orbit also ?
Cheers, Max
many thanks for the useful information. Actually, I meant to optimize the closed orbit rather than the trajectory.
What I meant was: I know that .FIN (where the parameters reside that are used by "optimize") carries the trajectory data. Is there an easy way to
carry the closed orbit also ?
Cheers, Max
-
- Posts: 1933
- Joined: 19 May 2008, 09:33
- Location: Argonne National Laboratory
- Contact:
Re: Location insensitive of the MALIGN element
Max,
Sorry I misunderstood your question. It is possible to optimize the closed orbit. You need to do three things:
1. Set CO_FITPOINT=1 on all HMON, VMON, and MONI elements that you'll want to use in the optimization. If you want to use them all, just add this command before the optimization_setup command:
&alter_elements name=*, type=*MON*, item=CO_FITPOINT, value=1 &end
2. Give a closed orbit command before the optimization_setup command, e.g.,
&closed_orbit
start_from_centroid = 0
&end
3. Make optimization_terms involving the monitors, e.g.,
&optimization_term
term = "HMON#1.xco sqr" &end
&optimization_term
term = "VMON#1.yco sqr" &end
This is illustrated in the attached files.
--Michael
Sorry I misunderstood your question. It is possible to optimize the closed orbit. You need to do three things:
1. Set CO_FITPOINT=1 on all HMON, VMON, and MONI elements that you'll want to use in the optimization. If you want to use them all, just add this command before the optimization_setup command:
&alter_elements name=*, type=*MON*, item=CO_FITPOINT, value=1 &end
2. Give a closed orbit command before the optimization_setup command, e.g.,
&closed_orbit
start_from_centroid = 0
&end
3. Make optimization_terms involving the monitors, e.g.,
&optimization_term
term = "HMON#1.xco sqr" &end
&optimization_term
term = "VMON#1.yco sqr" &end
This is illustrated in the attached files.
--Michael
- Attachments
-
- par10h.lte
- (2.45 KiB) Downloaded 671 times
-
- run.ele
- (1.56 KiB) Downloaded 652 times