madx file import

[simoneliuzzo]

Dear @lfarv,

The new feature of pyAT load_madx is extremely usefull. However, there are some files that appear difficult to convert such as the one attached here below, that includes hierarchic element class definitons.

Would it be easy to include this MADX feature in the conversion?

heb_ring_wcav_wqsc.txt

thank you
best regards

[lfarv]

Hello @simoneliuzzo,
I looked at your file. I get a lot of unexplainable error messages:

Unknown command 'vbpm' ignored: 'bpmn.s2.022 : vbpm'
Unknown command 'hcorr' ignored: 'hcorr.s2 : hcorr'
...

However it seems that the file is correctly processed. At least I get the "fcc_heb" sequence correctly (35938 elements).
Here is the simple way:

testfile = "/Users/laurent/dev/madfiles/liuzzo/heb_ring_wcav_wqsc.txt"
ring = load_madx(testfile,use="fcc_heb")
 Unknown command 'vbpm' ignored: 'bpmn.s2.022 : vbpm'
 Unknown command 'hcorr' ignored: 'hcorr.s2 : hcorr'
 ...
len(ring)
 35938

And the step-by-step way:

testfile = "/Users/laurent/dev/madfiles/liuzzo/heb_ring_wcav_wqsc.txt"
parser = MadxParser()
parser.parse_files(testfile)
 Unknown command 'vbpm' ignored: 'bpmn.s2.022 : vbpm'
 Unknown command 'hcorr' ignored: 'hcorr.s2 : hcorr'
 ...
parser["vbpm"]          # Check that "vbpm" is indeed existing
 vmonitor(name=vbpm, l=0)
ring = parser.lattice(use="fcc_heb")
len(ring)
 35938

I let you check if the result is correct…

Now I have to understand why we get these lots of error messages.

[simoneliuzzo]

Dear @lfarv,
thank you for looking into this!
I think the issue cames from inheritance of classes in MADX.

vbpm: Monitor

then later in the code

bpmn.s2.022: vbpm

or even

bpmn.s2: vbpm
bpmn.s2.022: bpmn.s2

those are all allowed definitions in MADX

[lfarv]

Yes, and it works indeed in AT also. As I said, your file seems to work correctly in spite of the error messages.
Can you tell me if the resulting AT lattice looks correct to you ?

[simoneliuzzo]

Dear @lfarv,

here my code for testing:

import at
import at.plot
import numpy

testfile = "/machfs/liuzzo/accelerator_toolbox_tests/python/load_madx/heb_ring_wcav_wqsc.seq"
ring = at.load_madx(testfile, use="fcc_heb")

# after conversion is a tuple, that the save_mat command does not like.
ring.in_file='/machfs/liuzzo/accelerator_toolbox_tests/python/load_madx/heb_ring_wcav_wqsc.seq'

at.save_mat(ring, './fccheb.mat', use='fcc_heb')
# at.get_optics(ring) # fails
# ring.plot_beta() # fails

# also lines below fail --> I use above matlab file for debug in transfer line mode.
ring.plot_beta(method=at.linopt2,
               twiss_in={'beta': [1., 1.],
                         'alpha': [0., 0.],
                         'mu': [0., 0.],
                         'closed_orbit': numpy.array([0., 0., 0., 0., 0., 0.])})

as you can read in the comments, get_optics and plotbeta fail. It also fails to plot_beta in trasnferline mode and save_mat does not work as apparently the output lattice has a tuple rather than a string for the in_file property.

So I switched to matlab for debug. There the transfer line mode plot is working and I get some result:

The element that breaks the optics computation is: mb2_dis2.a2.001a

atsbend('mb2_dis2.a2.001a', 0.0, 0.001450090741853, 0.0, madtype='sbend')

ans = 

  struct with fields:

          FamName: 'mb2_dis2.a2.001a'
       PassMethod: 'BndMPoleSymplectic4Pass'
           Length: 0
            Class: 'Bend'
     BendingAngle: 0.0015
    EntranceAngle: 0
        ExitAngle: 0
                K: 0
         PolynomB: [0 0]
         PolynomA: [0 0]
          madtype: 'sbend'
         MaxOrder: 0

only weird thing I can see is the Length=0.
So I assign (in matlab) to every dipole with length=0 a length of 1e-12. It fails. Then I try 1e-6. It fails. Then 1e-3. It WORKS!

% modify fcc_heb
load("fccheb.mat")
inds = find(atgetcells(fcc_heb,'Length') & atgetcells(fcc_heb,'Class','Bend'));
L = atgetfieldvalues(fcc_heb, inds,'Length');
fcc_heb_0 = atsetfieldvalues(fcc_heb,inds(L==0),'Length',1e-3);  % 1e-12 and 1e-6 fail

testind = find(atgetcells(fcc_heb_0,'FamName','mb.a2.051b'),1,'first');
fcc_heb_0{testind}

atplot(fcc_heb_0,[0,3000],'twiss_in',struct('beta',[1.0,1.0],'alpha',[0.0,0.0],'mu',[0.0,0.0]),'labels',1:1000)

atplot(fcc_heb_0)

and atplot(fcc_heb) gives optics!

[simoneliuzzo]

The summary of findings is:

• zero lengths dipoles do not seem to work.
• transferline plot_beta does not seem to work in pyAT, or I gave bad inputs (in this case, could help an example block in the help of plot_beta)
• there may be a bug with the field in_file for the Lattice produced by load_madx

[lfarv]

@simoneliuzzo : Very nice analysis, thanks ! It's very useful for improving the conversion.

For the consequences:

• the in_file problem can probably be solved even if I don't yet know how: the tuple exists because you can potentially give several files as input, as it is a common practice in MADX.
• I'll look at the problem of the transfer line plot. Apparently it's uncorrelated with the parsing of MAD files,
• Dipoles with zero length are clearly not acceptable in AT: it gives an infinite magnetic field, infinite inverse bending radius, infinite horizontal focusing, infinite radiation and consequently lot of numerical problems. I even don't know if it makes sense. If such elements appear in MADX, they should be converted into something else, presumably with IdentityPass. A short length is not a solution, it still leads to huge and unrealistic radiated power

For 0 length bending magnets, let's look at a comparison with straight magnets:

• For straight magnets there is a limit for length approach 0 with constant integrated gradient: it's the ThinMPolePass. But it cannot be used with radiation because it also gives infinite radiation. That's why there will never be a ThinMPoleRadPass
• For curved magnets, there is no limit for length approaching 0 with constant or even null integrated gradient, because of the additional horizontal focusing strength in $1/\rho^2$ which also goes to infinity. Even using a small length introduces a large and non-physical focusing.

That's why I think that the only realistic solution for these elements is to ignore them.

[lfarv]

@simoneliuzzo : by the way, can you check what happens if you set the PathMethod of zero-length dipoles to IdentityPass, instead of changing their length to 1.0e-3? Thanks

[simoneliuzzo]

Dear @lfarv ,

apparently in MADX the dipole length is there, 11 meters (B. Dalena sent me the code) .

const l_mb = 11;
a_dis.s2 = -0.3;
th_mb_dis.a2 = 0.00111545441681;
mb: sbend,l:=l_mb ;
mb2_dis2.a2: mb,angle:=th_mb_dis.a2 * ( 1 - a_dis.s2 ) ;
mb2_dis2.a2.001a: mb2_dis2.a2;

I checked the IdentityPass solution, here the results:

It looks a nice solution.

[lfarv]

@simoneliuzzo : Ok, so the forget the previous posts, a zero-length dipole is indeed non-physical, but the problem now is in the conversion. I look at that, thanks

[lfarv]

The problem is in the "const" keyword, I never encountered it before and I missed it in the documentation. I have to look at what it means exactly.

[lfarv]

Solved in #824