MethodicalAcceleratorDesign
Changeref not connected
The Changeref element is not connected while all sub-patches required for its implementation are there. Twiss has a guard emitting a warning, but not Track nor Survey. We should maybe discuss the order of the sub-patches to ensure the compatibility with MAD-NG (including attributes names, to be discussed). https://github.com/MethodicalAcceleratorDesign/MAD/blob/dev/src/madl_dynmap.mad#L241 (Track, Twiss) https://github.com/MethodicalAcceleratorDesign/MAD/blob/dev/src/madl_geomap.mad#L121 (Survey)
Script provided by David Sagan, the Bmad order for things is given in section 14.2.4 of the Bmad manual:
!!option,-echo,-warn;
l1: sequence l=0.0001;
p: changeref, at=0, patch_trans = 0.1, 0, 0;
p2: translation, at=0, dx = 0.02;
endsequence;
bstart: beta0, betx=1,bety=1, x=1e-3, dx=0.01, dpx= 0.001, x=0, px=0e-3;
beam, energy = 1;
use, period=l1;
!!twiss,sequence=l1,file= twiss.tfs ,beta0=bstart;
select, flag=survey, column=name,l,angle,x,y,z,theta;
survey,file="out”;
The result is:
erpsim1:~/dcs16/mad/madx-test> cat out
@ NAME %06s "SURVEY"
@ TYPE %06s "SURVEY"
@ TITLE %08s "no-title"
@ ORIGIN %16s "5.05.02 Linux 64"
@ DATE %08s "25/04/20"
@ TIME %08s "18.05.57"
* NAME L ANGLE X Y Z THETA
$ %s %le %le %le %le %le %le
"L1$START" 0 0 0 0 0 0
"P" 0 0 0 0 0 0
"P2" 0 0 0.02 0 0 0
"DRIFT_0" 0.0001 0 0.02 0 0.0001 0
"L1$END" 0 0 0.02 0 0.0001 0
This point is postponed as MAD-X is lacking other patches and a clear definition of the order to apply the patches.
I'd prefer it if this weren't postponed, because this is creating problems for me. More specifically, I don't care if it is CHANGEREF per se, but there is a problem that a general coordinate transformation cannot be implemented in a way that works across all algorithms. If I want PTC and SURVEY to both work, I run into the problem that SURVEY does not implement CHANGEREF, while it does implement TRANSLATION and *ROTATION, while PTC implements CHANGEREF but it does not implement TRANSLATION (or XROTATION). The easy thing to do is to have everything implement TRANSLATION and *ROTATION, that way there's no ordering ambiguity in the coordinate changes, though it would make for more compact lattice files for many cases if there were a well-defined CHANGEREF as well.
Thanks for your feedback! We will try to fix this in the comming weeks but we also need some internal discussion to decide which way is the best. At the moment we are in the middle of a release but will try to solve this as soon as possible.
If I understand you correctly, you would like a command that changes the coordinates in PTC as well as the survey ?
Yes: it's important for some more complicated geometries (the EIC hadron IR in this case) to be able to insert a general coordinate transformation into a beamline. Right now there is no way to do this that works across all algorithms in MAD-X. The case I've been working on is getting SURVEY and PTC_TWISS to work, I haven't checked exhaustively through the other algorithms so there may be other problems. It would be good if the release had at least one way to do this consistently, otherwise I can't produce a single lattice file that works for everything, and it would be nice to be able to tell people to use 5.06. Getting PTC to work is trivial as you can see from the pull request I put up (I didn't do XROTATION, but it is equally trivial except for the work required for sign checking). CHANGEREF would be nicer, of course, but would likely be much more work to get working, and having one thing that works is what is most important.
I will try to solve this once and for all in the comming weeks but for now I would recommend that you either use your own version of MAD-X or the PTC eplacment (link to documentation below) with the additional complication that this is not recognised by the normal MAD-X survey meaning that this would have to be added to the MAD-X and the removed before PTC. http://madx.web.cern.ch/madx/madX/doc/usrguide/ptc_auxiliaries/PTC_EPlacement.html
EPLACEMENT doesn't actually solve the problem since it just allows the displacement of the element, I need to be able to place the coordinate system origin at the location where the particle ends up after it has gone through a series of magnets whose positions are not centered on the beam, so TRANSLATION/YROTATION or CHANGEREF are essential. It's kind of important that I use features that are available in a standard MAD-X version since the purpose of this exercise is to produce a version of the lattice for MAD-X users.
I added XROTATION to the pull request (#941) as well. That should enable PTC to do the the full set of transformations.
Sorry to take a while getting back to you. TWISS doesn't get the dispersion right. See 210309b.txt, which is just a complicated way to write a 2 m drift with some translations and rotations. TWISS gets the dispersion wrong (PTC_TWISS does just fine). The orbit is fine. I haven't checked Z translation or time as yet.