New integrators: ExactDriftPass, ExactMultipolePass

[lfarv]

New integrators for drifts and straight multipoles.

[lfarv]

Removed a sanity check on loading Matlab files blocking ExactDriftPass

[lfarv]

Added ExactRectangularBendPass and ExactRectangularBendRadPass.

Note that ExactRectangularBendPass now accepts pole face angles. So it can be used to replace any dipole without higher order terms. Using it for focusing magnets is delicate since the reference trajectory is no more an arc of a circle. So it's likely to generate a non-zero closed orbit… An ExactSectorBendPass is in preparation and will avoid those problems.

[simoneliuzzo]

Dear @lfarv and @swhite2401 , I start again today to test this branch vs MADX-PTC. I will keep you posted with the results.

[simoneliuzzo]

Dear @lfarv and @swhite2401,

below my actual status of comparison AT vs MADX-PTC

I take the same identical initial coordinates (20 points up to the same number of sigmas in x, xp, y and yp, a 4D diagonal, no initial dpp or ct). I verify that tracking in AT and MADX-PTC are consistent (radiation, exact hamiltonian, fringe fields, number of integration steps (80), etc..) Then I take an AT lattice, convert it to MADX and build figures to compare.

For the ESRF-DBA lattice, there is a well comparing case, but works only in 4D, not in 6D.

For the EBS lattice, I see no effect of exact pass (ok) but the AT and MADX-PTC tracking are visibly different.

For the FCC lattice, there is a well comparing case (the same of ESRF-DBA, 4D). In 6D only the particle at 0.0 initial coordinates survives.

For all cases I could not yet convert properly the longitudinal phase space from MADX-PTC to AT convention. I will spend some time on this issue now, so I should be able to show you also the missing phase space plot in the next message.

Conclusion for now is:

• with atdisable_6d using all Exact pass methods makes AT and PTC tracking close to identical for DBA and FCC (not for EBS, may be dipole quadrupoles are the issue?).
• with atenable_6d there are still issues
• as soon as I introduce initial delta or ct to the tracked particles the two codes tracking start to be relevantly different
• 4D tracking in AT and MAD-PTC without exact integrators are different

[simoneliuzzo]

Dear @lfarv and @swhite2401,

I have noticed that in my simulations for EBS (only) I never actually used ExactRectangularBendPass.

With this PassMethod in the DQ the optics become largely mis-matched. May be this pass method is not ready to accept Quadrupole components?

Also the ExactRectangularBendRadPass seems to have some issue. As soon as I use it the tracking fails (only the zero amplitude particles survive).

May be I am not supposed to test with it. For the ESRF-DBA and FCC lattices, using it the 4D tracking agrees with MADX-PTC.

Unfortunately in MADX it is not possible to enable exact integrators only in some magnets. All or nothing.

Looking forward to ExactSectorBendPass and ExactSectorBendRadPass!

thank you for your help simone

[lfarv]

@simoneliuzzo You should not use the RectangularBendPass for DQs for 2 reasons:

1. DQs are not straight magnets: their magnetic axis is an arc of a circle. In rectangular bends the magnetic axis is a straight line (like in a displaced quadrupole). For pure dipoles it does not matter, the magnetic field is uniform. If there are other multipoles, it does matter,
2. When discussing rectangular bends on my last visit, I pointed out that for non-uniform field, we are still missing a tuning function: if there are multipoles, the trajectory in the magnet is no more an arc of a circle. For arbitrary multipoles, it cannot be predicted. We need a tuning function which will iteratively displace the magnet until the nominal deviation is achieved. I promised you this function, but I didn't do it yet. The path length has also to be tuned. Until this is available, and unless you want iterate manually, you are restricted to pure dipolar field: ESRF-DBA is OK.

Did the RadPass methods fails on ESRF-DBA ? That's an interesting.

I did not come back the sector bends, I've been busy with tapering, but I'll switch to that soon!

[simoneliuzzo]

Ok. I stop testing for now. The tools are in place on my side.

Yes, the ESRF-DBA lattice fails with ExactRectangularRadPass

4D

6D

In particular the AT lattice has very strange optics, tunes, chromaticity. I use the AT lattice to generate coordinates for tracking and they are NAN (NAN emittances, energy spread, etc). Consequently the converted MADX also fails tracking, but optics are perfectly fine.

I attach here the failing lattice. lattice.m.zip

and the output of ringpara and atx

   ******** AT Ring Parameter Summary ********
   Energy:                      6.00000 [GeV]
   Circumference:               844.39069 [m]
   Revolution time:             2816.58417 [ns] (0.35504 [MHz]) 
   Betatron tune H:             NaN ( NaN [kHz])
                 V:             NaN ( NaN [kHz])
   Chromaticity H:              NaN
                V:              NaN
   Synchrotron Integral 1:      NaN [m]
                        2:      2.60359e-01 [m^-1]
                        3:      1.09718e-02 [m^-2]
                        4:      NaN [m^-1]
                        5:      NaN [m^-1]
   Damping Partition H:         NaN
                     V:         1.00000
                     E:         NaN
   Radiation Loss:              4746.84462 [keV]
   Natural Energy Spread:       NaN
   Natural Emittance:           NaN [nm]
   Radiation Damping H:         NaN [ms]
                     V:         7.12031 [ms]
                     E:         NaN [ms]
   Momentum Compaction Factor:  NaN
   Slip factor:                 NaN

   Assuming cavities Voltage:   9000.00000 [kV]
                   Frequency:   352.19966 [MHz]
             Harmonic Number:   992
   Synchronous Phase:           2.58602 [rad] ( 148.16822 [deg])
   Linear Energy Acceptance:    NaN %
   Synchrotron Tune:            NaN ( NaN kHz or  NaN turns) 
   Bunch Length:                NaN [mm],  NaN [ps]

   Emitty from Dy:              NaN [nm]
   Emitty 1/gamma cone limit:   NaN [pm]
>> [a,b] =atx(r)
Warning: Matrix is singular, close to singular or badly scaled. Results may be inaccurate. RCOND = NaN. 
> In xorbit_6 (line 47)
In findorbit/xfindorbit (line 44)
In frequency_control (line 28)
In findorbit (line 33)
In findm66/xfindm66 (line 72)
In frequency_control (line 28)
In findm66 (line 52)
In ohmienvelope (line 27)
In atx/go (line 195)
In atx (line 116)

Warning: Matrix is singular, close to singular or badly scaled. Results may be inaccurate. RCOND = NaN. 
> In ohmienvelope (line 55)
In atx/go (line 195)
In atx (line 116)

Warning: Emittance computation failed:
First and second inputs must not contain NaN or Inf.

> In atx/go (line 208)
In atx (line 116) 

a = 

  1×1637 struct array with fields:

    R
    M
    A
    mu
    SPos
    ClosedOrbit
    alpha
    beta
    Dispersion
    modemit
    emit44
    emit66

b = 

  struct with fields:

              ll: 8.443906927513550e+02
           alpha: 1.779465694145638e-04
       fractunes: [0.440020226187056 0.389996716488082]
       fulltunes: [36.440020226187059 13.389996716488083]
             nuh: 36.440020226187059
             nuv: 13.389996716488083
    chromaticity: [7.254689719330779 11.832685785565880]
     dampingtime: [NaN NaN NaN]
        dampingJ: [NaN NaN NaN]
         espread: NaN
         blength: NaN
    modemittance: [NaN NaN NaN]
          energy: 6.000000000000000e+09
              fs: NaN
           eloss: 0
    synchrophase: 0
      momcompact: 1.779465694145638e-04

thank you for your work
best regards
Simone

[lfarv]

@simoneliuzzo: got your lattice, I'm looking at it.

[simoneliuzzo]

Dear @lfarv

thank you for the fast update. In fact the ExactRectangularBendRadPass is now giving stable lattices.

However, when using the *Rad version of ExactMultipolePass and ExactRectangularBendPass the tracking in the px, y and py planes differs more from the MADX-PTC one (the x plane tracking instead is even more similar to the MADX one than without rad) compared to the 4D case.

4D (madx does not track ct and delta)

6D

thank you for your help best regards Simone

[simoneliuzzo]

Dear @lfarv let me know when I should run my benchmark test for this branch. thank you! best regards Simone

[swhite2401]

when using the *Rad version of ExactMultipolePass and ExactRectangularBendPass the tracking in the px, y and py planes differs

It seems the Rad passes are now incorrect, have we found the problem? It would be nice to finalize the PR, it seems we are very close and working on a dev branch is really not comfortable.

Can I help in some way to speed this up?

[simoneliuzzo]

Dear @lfarv,

let me know when I have to run the test.

I have tried ExactSectorBendPass and it is in agreement with MADX

[lfarv]

Hello @simoneliuzzo,

I'll send you next Monday a review of where I am on that (I'm away for the end of the week). I ran many tests and still found a number of issues, from minor to critical, the main one being ExactSectorBendRadPass (still not working).

Your test of ExactSectorBendPass looks very nice, though this passmethod has still some small problems for me: more next Monday…

[lfarv]

@simoneliuzzo

Here is the status of "exact" passmethods:

• ExactRectangularBendPass is OK for me,
• ExactRectangularBendRadPass is OK for me. I do not know how PTC handles radiation. I handle it as in other places: at each kick, compute the momentum change and apply it keeping the angles. In other passmethods, AT applies 1st the momentum change and then the kick (bending or focusing). I do not know why in that order. I can try half-kick, momentum change, half-kick to see if it makes a difference,
• ExactSectorBendPass looks OK. But there is a slight numerical problem. If I compare the horizontal tune, I get this: Zooming around dp=0 gives this: There is a ripple of about 2.0e-5 in horizontal tune at around dp=0. This is not tremendous but it ruins the computation of chromaticity with the standard parameters. It's a numerical problem with Forest's formulae (like subtracting two very close floating point numbers). I'm investigating this,
• ExactSectorBendRadPass is completely wrong. The final momentum loss is correct, but the kick are crazy…

And finally, E. Forest gives an alternative formula for RectangularPass, extrapolated from the general SectorPass. I called it ExactRectBEndPass for the moment. It has a big advantage: like ExactSectorBendPass, since it's an exact analytic formula, if the is no multipole or radiation, it does not need any splitting of the magnet. By setting NumIntSteps=0, we gain a factor ten to twenty in speed ! But it suffers from the same problems as SectorPass, so forget it for the moment.

[simoneliuzzo]

Dear @lfarv ,

thank you for the update. Let me know if there is something I can do to help apart running the benchmark with MADX-PTC.

regards Simone

[lfarv]

@simoneliuzzo, @swhite2401 : This version is now ready for tests.

It includes:

• ExactDriftPass
• ExactMultipolePass
• ExactRectangularBendPass
• ExactSectorBendPass

and

• ExactMultipoleRadPass
• ExactRectangularBendRadPass
• ExactSectorBendRadPass

Most of the problems are solved, but the numerical ripple is still there, with the following consequence: the steps used for computing the transfer matrices and the chromaticities must be increased with respect to the default values, depending on the lattice. In the worst case, I had to increase DPStep from 1.e-6 to 1.e-3 and XYStep for 1.e-8 to 1.e-5. The way to do that is:

Matlab:

setoption('XYStep',1.e-5)
setoption('DPStep',1.e-3)

python:

at.DConstant.XYStep=1.e-5
at.DConstant.DPStep=1.e-3

For the 3 *RadPass methods, I changed the kick sequence (at each integration step) from "radiation kick, multipole kick" to "half multipole kick, radiation kick, half multipole kick" which looks better for me.

There my still be a few problems, let me know.

[lfarv]

This version is rebased on the last master commit, so it includes all the recent fixes of the master branch.

[simoneliuzzo]

Dear @lfarv and @swhite2401 ,

@lfarv, thank you for these updates! They sounds very promising.

I have started now the benchmark with madx-ptc.

I'll send the plots as soon as I can.

regards Simone

[simoneliuzzo]

Dear @lfarv and @swhite2401,

This is the overall summary of the benchmark for the ESRF DBA lattice:

ExactSectorBendPass works as well as ExactRectangularBendPass

The *Rad are still a bit different:

BndMPoleSymplectic:

ExactRectangularBend:

ExactSectorBend:

[lfarv]

@simoneliuzzo: Thanks for this fast benchmark. It looks very promising. My comments:

1. If there is no multipole in the dipoles, ExactRectangularBend and ExactSectorBend should be identical. Apparently you confirm that: nice !
2. On the right part of the plot (radiation on), it looks like all three AT results are identical… Is it true? In my tests, the tracking is clearly different between BndMPoleSymplectic4RadPass and ExactSectorBendRadPass. Or do I miss something?
3. If there is no radiation nor multipole components, in ExactSectorBendRadPass you can set NumIntSteps=0. Then there is no slicing of the magnet, so much faster tracking and much less numerical noise. Could you check this? Otherwise (radiation or multipole components), I found an optimum NumIntSteps between 10 and 20. Above, the noise increases.
4. As I told you previously, there is an alternate solution for straight magnets, which I called ExactRectBendPass. It should be identical to ExactRectangularBendPass but instead of using a drift-kick sequence, it uses a bend-kick sequence, as in ExactSectorBendPass. The bend is analytically computed, so if there is no multipole kick, it can also be used with NumIntSteps=0. Can you add this to your test?
5. It could be interesting to check the focusing in dipoles (ExactSectorBendPass only). Can you try another lattice?

[simoneliuzzo]

Dear @lfarv,

I run the same code for EBS. Contrary to the DBA lattice when setting ExactRectangularBendPass the emittance computation fails (ringpara gives negative emittance, atx does not work for the rad-off case) and so my definition of initial coordinates for tracking is not real.

The optics of the lattice are mis-matched by the change of integrators in the dipoles.

With ExactSectorBendPass atplot does not show the optics (eig input matrix must not containt inf or nan).

[lfarv]

@simoneliuzzo: thanks for feedback

1. you cannot use ExactRectangularBend for DQs, since they are not rectangular magnets. But you can for DLs. Is this what you tried?
2. For ExactSectorBend, it seems that the problem is a septum magnet with a zero bending angle. There must be a problem with zero bending angle in sector bends. I'll look at that, but in the meantime, can you test ExactSectorBend with excluding the septum, or any other magnet with zero angle? Thanks

[lfarv]

@simoneliuzzo : the problem with zero bending angle is corrected, you can try again.

[lfarv]

@simoneliuzzo, @swhite2401

The "Exact" passmethods are now ready for review. The tuning function for the rectangular magnets is now available and documented.

• Matlab: function atrbendtune(elem). Try >> help atrbendtune

  % Identify the rectangular bends (for example...)
  rbends=atgetcells(ring,'PassMethod', 'ExactRectangularBendPass');
  % Set their correct attributes
  ring(rbends)=cellfun(@attunerbend,ring(rbends),'UniformOutput',false);

• python: Dipole.rbendtune() method. Try >>> help(at.Dipole.rbendtune).

  # Identify the rectangular bends (for example...)
  rbends = ring.get_bool_index(checkattr("PassMethod", "ExactRectangularBendPass")
  # Set their correct attributes
  for dip in ring.select(rbends):
    dip.rbendtune()

  The new pass methods are also documented on the Web pages, in a preliminary documentation of all passmethods. Please have a look and post you comments.

[swhite2401]

Very nice addition! I trust you on the math providing @simoneliuzzo benchmarking is ok. Adding a documentation section is also very good and this practice should be extended, however I think it would also be very usefull to add something in the docstrings or the element class to describe the available passmethods and basic functionalities, arguments etc... This element is becoming complicated... do you want to create a class ExactDipole?

The method to tune the dipoles could be added as a member of the class.

[lfarv]

This element is becoming complicated... do you want to create a class ExactDipole?

I would prefer keeping a single dipole class, so that you can easily change the passmethod keeping the same element. The only additional complexity is the new tuning method.

The method to tune the dipoles could be added as a member of the class.

It is the case, and it's the only way to access it. As explained in the docstring, it does nothing if the passmethod is not a rectangular pass, so you can run it safely for any dipole.

Concerning docstrings, you are right, but it's a more general question. At the moment, the attributes and methods are documented, and the default passmethod is mentioned (for all classes). A simple addition could be to mention all the acceptable passmethods, with a link to the global passmethod descriptions that I just initiated. Can this be set as another PR? The passmethod description is still preliminary, I just took care of the new "Exact" methods

[swhite2401]

Yes adding accepted passmethods would be the minimum, but in this case more needs to be done because different passmethods taken different input arguments, can we add notes as well to describe the arguments/functions specific to each passmethods?

What about unit tests?

Ok let's keep one class.

Documentation needs a lot of work in general... a new PR is probably ok. However we really have to put some effort into it, this was one clear outcome of the workshop. I would suggest to make the new realease with ongoing devs but after that all efforts should concentrate on improving the docs... this is not fun but has to be done....

[lfarv]

There are still things that can be changed:

• the name of the tuning function. Any better idea?
• in python, I tried not to lengthen the element.py module (already 1192 lines), so I implemented the new method in a separate file. Is it the best way? Or should we move the entire Dipole class to a separate file?
• The new bend classes have an optional possibility for multipole fringe field. At the moment, I kept this private until we find the best way to integrate this new flag in the existing attributes (a new value to the FringeQuadEntrance integer flag?).
• Same for the dipole fringe field: a new gK variable looks identical to the product of the existing FullGap*FringeInt1 attributes (usually at 0). It needs to be checked, I could not find until now what gK refers to…
• There is an alternate method for rectangular bends, presently called ExactRectBendPass. It gives the same result as ExactRectangularBendPass with an advantage (a single step for pure dipole field) and a drawback (small discontinuity around the origin as for the sector bend). It is also considered private for now, but I'd like you to test it.

[swhite2401]

• in python, I tried not to lengthen the element.py module (already 1192 lines), so I implemented the new method in a separate file. Is it the best way? Or should we move the entire Dipole class to a separate file?

In fact I was about to suggest some re-organization of this part, can we separate elements by type, magnets, diagnostics, etc... ? I think this would make things more readable. But this is probably for another PR

[lfarv]

different passmethods taken different input arguments, can we add notes as well to describe the arguments/functions specific to each passmethods?

That's exactly what I did in the passmethod description I started: it shows how the method works and what attributes it uses. The mention of the available passmethod in the element class doctoring must link to that. I'll try right now for the dipole class, you'll tell me what you think of it.

[simoneliuzzo]

Would it be possible to add atrbendtune in the atrbend element creator?

here a few proposal for different names: at_set_rectangual_exact_bend_parameters at_set_rbend_X0_DZ_ref

Why are the two additional fields name X0ref and RefDZ ? Is it for consistency with notation in the references?

[lfarv]

@swhite2401: can you now look again at the doc of the Dipole class: it now points to the full description of all the available passmethods (at least those that I have documented…). It can still be improved and generalised, but I think it's the way to go.

[lfarv]

@simoneliuzzo I agree that the attribute names are not very nice, but it's their name in @catohxb's BndStrMPoleSymplectic4Pass where they have the same role (and the same values after tuning). I borrowed them from there and I'd like to keep the same attribute names everywhere.

It would be easy to call the tuning function within the element creation, but I fear that if it's hidden, users would forget to call it after modifying PolynomB. That's why I preferred to keep it explicit. If there is a common agreement to include it, why not. And what about python?

About names: yours are quite long, and Matlab style for function names is to use camelCase rather that underscores (opposite to python)… Any preference @swhite2401, @carmignani ?

[simoneliuzzo]

Dear @lfarv

I have run the benchmark again. However something is strange.

with AT from 12 September I get the improvement in benchmark as in this figure, while with the latest AT (pulled today 9 October) instead I do not get it anymore.

This is true already for ExactDrift and ExactMultipole integrators.

and even more evident when including ExactRectangularBend

Did anything change that could explain this change?

[lfarv]

@simoneliuzzo : Strange indeed

• ExactDrift and ExactMultipole did not change at all
• ExactSectorBend has an additional check to avoid problems with a 0 bending angle (a problem you had with EBS), but no change in the computation,
• ExactRectangularBend has the addition of the 2 new tuning attributes, but no change in the computation,

For me, the results did not change since long. Are you sure you are on the right branch and rebuilt everything (atmexall?). By the way, are you running Matlab or python ?

[lfarv]

@simoneliuzzo : If you confirm today's problem, I'd like you to repeat you September test. You can go back to the code of September 12th by typing:

git checkout 1113ed0

You can come back to today's version with:

git checkout exact_multipole_pass

Don't forget to rebuild everything when switching versions: for Matlab:

atmexall

For python:

rm -rf build
pip install . # (or pip install -e .)

[simoneliuzzo]

Dear @lfarv ,

my matlab benchmark code does this. Every time I download a new AT, give it a name, run atmexall and run the tests. So I can go back to the frozen version I downloaded on the day of test.

clear
close all

format long

warning('off','all')

atfolder = 'at_9Oct2023';
% atfolder = 'at_12Sept2023';

% use local AT
restoredefaultpath;

% rmpath(genpath('/machfs/liuzzo/EBS/beamdyn/at/atintegrators'))
% rmpath(genpath('/machfs/liuzzo/EBS/beamdyn/at/atmat'))

addpath('/machfs/liuzzo/EBS/beamdyn/matlab/matlab_extensions/export_fig-master')

% add local AT folders
addpath(genpath(['./' atfolder '/atintegrators']))
addpath(genpath(['./' atfolder '/atmat']))
addpath('.');

branch = 'exact_multipole_pass';

cd(['./' atfolder ])
system(['git checkout ' branch]);
cd('..');

if ~exist(['./' atfolder '/atintegrators/AperturePass.mexa64'],'file')
    cd(['./' atfolder '/atintegrators'])
    atmexall
    warning('remember to change RF=1.0 in line 31 of at/atmat/lattice/Converters/AT2MADX/AT_2_MADX.m')
end
warning('on','all')

warning('off','all')

I will check if there is something that did not go well, but since I could easily recompute the data for September 2023 I am rather confident I did the correct thing. May be the X*X modification had some unwanted effect?

[lfarv]

@simoneliuzzo : sorry if I look too suspicious, but I would feel safer if you could restart from scratch from the git repository (commit 1113ed0).

I went carefully though all the modifications since September 12 and none can affect the results. I found a bug fix for "radiation" methods (*RadPass) which should be different, but not for "plain" methods.

In the worst case, if you confirm that commit 1113ed0 gives better results, I can "replay" one by one all the modifications and check all along, but that looks really unlikely…

[lfarv]

@simoneliuzzo : a question about your script: in

cd(['./' atfolder ])
system(['git checkout ' branch]);
cd('..');

• If the folder is empty, git checkout is unable the make a new clone (no reference to the remote repository). You must use git clone,
• if the folder is already a git working space, git checkout exact_multipole_pass switches to the branch exact_multipole_pass, but does not update it. In addition you must call git pull

So there is for sure something else than what you show… I'd like to see the whole story

[simoneliuzzo]

Dear Laurent,

the commit you mention does not seem to exist, but is also mentioned above in this conversation.

I took an other one 3bc224d. Problem was not present.

I took an other one bbc5346. Problem was present.

Concerning the matlab code for my tests, I definitely do not want to checkout and pull. I clone a new AT copy when I need to run a new test and that is my reference copy, no need to remember the latest commit code. Frozen forever, exactly to be able to reproduce previous results.

[lfarv]

Hi @simoneliuzzo, thanks for investigating, it's indeed crucial.

https://github.com/atcollab/at/commit/3bc224dfc15b3562b3bea219bbbc68a03b6679e4 is very old (March 14), and https://github.com/atcollab/at/commit/bbc53461c9d5d662c47b77ecb17aab8af9a3f612 is very recent (October 5).

In the history, I find 4a68ffa1 from September 11, just before you ran your successful test. This one should be correct. The problem must lie after this one.

You say that the problem involves ExactDriftPass or ExactMultipolePass (at least). ExactDrift did not change since July, ExactMultipole changed 3 times since September 11:

• 90d3a21d 12/09 - Send error if NumIntSteps <= 0
• 0b032310 14/09 - Add the FieldScaling attribute for radiation tapering. Disabled unless there is a FieldScaling in your magnets.
• 488ceef7 14/09 - Use the standard attribute names for multipole fringe fields. Disabled unless there is a FringeQuadEntrance or FringeQuadExit in your magnets. Same for bending magnets by the way: if there is some of these flags, it may have activated some fringe field effects in the last modifications

Can you check that you are not in one of these cases ?

Otherwise, you may try these commits, but don't rush, there is no pressure to merge. I continue investigating on my side but I'm leaving tomorrow for one week.

Concerning the matlab code for my tests, I definitely do not want to checkout and pull. I clone a new AT copy when I need to run a new test and that is my reference copy, no need to remember the latest commit code. Frozen forever, exactly to be able to reproduce previous results.

Perfect. I was just surprised because the "clone" does not appear in your script. Could you just in addition record the commit hash corresponding to each of your clones ? It helps a lot in browsing the history of the code.

[simoneliuzzo]

The DBA lattice I am using has FringeQuad = 1. In MADX I set fringe effects to FALSE for all cases. If I remove them I am back to good agreement. Basically the initial version of the pass methods automatically ignored them, now I have to explicitly remove the field or set them to 0. The comparison is working again. The difference AT-MADX for the 6D case is still present. 4D

6D

[lfarv]

@simoneliuzzo

Excellent ! Indeed, fringe field effects can now be activated with the standard attributes, but the default is to disable them.

I see that you tried the ExactRectBendPass with good results. I think I'll include it also, with the adequate documentation.

Could you retry the test on EBS to check the dipoles with gradients (ExactSectorBend for the DQs)? The problem with the septum magnet should be solved. No pressure again…

Since I'll be away for one week, that leaves you this time for the last remarks (naming, documentation,…)

[swhite2401]

Documentation is indeed on the right track, to be further developed in separate PRs, for me this is fine

[simoneliuzzo]

Dear @lfarv,

Do you think the discrepancy in 6D is not relevant?

Before merging I would like to test for EBS and also for FCC, that is the lattice where the EXACT methods should give a non negligible effect.

ciao simone

[simoneliuzzo]

Dear @lfarv and @swhite2401 ,

Here a summary for DBA:

The first column Identity pass corresponds to comparison with MADX-PTC with exact flag = false. all other columns corresponds to comparison with MADX-PTC with exact flag = True.

4D all seems ok is the Drift, Bend and Multipole Exact integrators are used. comparison concerns only x,xp,y,yp. 6D the ExactMultipolePass seems to add some issue. comparison of all coordinates. largest discrepancies in transverse plane.

I will now repeat for EBS

[lfarv]

@simoneliuzzo :

Do you think the discrepancy in 6D is not relevant?

The discrepancy is not huge. But what I'm saying is that I treat the radiation as it is done elsewhere in AT: at each integration step, I apply:

• 1st half the magnetic field kick
• radiation kick
• 2nd half of the magnetic field kick

That look correct to me, but I have no idea of what PTC is doing. So until we have further information, I propose to keep this: in terms of energy loss and damping time it's correct.

Before merging I would like to test for EBS and also for FCC, that is the lattice where the EXACT methods should give a non negligible effect.

Sure, you have time! Lattices where the dipole exact pass methods are critical are small machines, because of a small bending radius and of large particle angles. Not the case of FCC, but I guess the problem there is not the dipoles (which should be very close to straight sections).

[simoneliuzzo]

Dear @lfarv,

indeed for FCC the change due to exact integrators originates in drifts and quads at the IP.

best regards simone

[simoneliuzzo]

Dear @lfarv,

for EBS lattice, the inclusion of ExactRectangularBendPass makes atlinopt6 fail.

Here the first two dipoles:

               FamName: 'S3_Septum'
            PassMethod: 'ExactRectangularBendPass'
                Length: 0.530000000000000
                 Class: 'Bend'
          BendingAngle: 0
         EntranceAngle: 0
             ExitAngle: 0
              PolynomB: [0 0]
           NumIntSteps: 80
              PolynomA: [0 0]
              MaxOrder: 1
    FringeQuadEntrance: 0
        FringeQuadExit: 0
            RApertures: [-0.015000000000000 0.025000000000000 -0.016000000000000 0.016000000000000]
                 X0ref: NaN
                 RefDZ: NaN

ans = 

  struct with fields:

               FamName: 'JL1A_5'
            PassMethod: 'ExactRectangularBendPass'
                Length: 0.375000000000000
                 Class: 'Bend'
          BendingAngle: 0.006386125083674
         EntranceAngle: 0.003193062500000
             ExitAngle: 2.182400000000000e-05
              PolynomB: [0 0]
           NumIntSteps: 80
              PolynomA: [0 0]
              MaxOrder: 1
    FringeQuadEntrance: 0
        FringeQuadExit: 0
            EApertures: [0.025000000000000 0.010000000000000]
                 X0ref: -1.995663240884306e-04
                 RefDZ: -6.328713440617911e-07

the NaN in the septum are a potential candidate? I keep looking for an exact reason.

[simoneliuzzo]

Same is true for ExactRectBendPass. ExactSectorBendPass instead runs ok.