Closed lfarv closed 10 months ago
Removed a sanity check on loading Matlab files blocking ExactDriftPass
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.
Dear @lfarv and @swhite2401 , I start again today to test this branch vs MADX-PTC. I will keep you posted with the results.
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:
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
@simoneliuzzo You should not use the RectangularBendPass for DQs for 2 reasons:
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!
Ok. I stop testing for now. The tools are in place on my side.
Yes, the ESRF-DBA lattice fails with ExactRectangularRad
Pass
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
@simoneliuzzo: got your lattice, I'm looking at it.
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
Dear @lfarv let me know when I should run my benchmark test for this branch. thank you! best regards Simone
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?
Dear @lfarv,
let me know when I have to run the test.
I have tried ExactSectorBendPass and it is in agreement with MADX
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…
@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:
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.
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
@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.
This version is rebased on the last master commit, so it includes all the recent fixes of the master branch.
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
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:
@simoneliuzzo: Thanks for this fast benchmark. It looks very promising. My comments:
ExactRectangularBend
and ExactSectorBend
should be identical. Apparently you confirm that: nice !BndMPoleSymplectic4RadPass
and ExactSectorBendRadPass
. Or do I miss something?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.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?ExactSectorBendPass
only). Can you try another lattice?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).
@simoneliuzzo: thanks for feedback
ExactRectangularBend
for DQs, since they are not rectangular magnets. But you can for DLs. Is this what you tried?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@simoneliuzzo : the problem with zero bending angle is corrected, you can try again.
@simoneliuzzo, @swhite2401
The "Exact" passmethods are now ready for review. The tuning function for the rectangular magnets is now available and documented.
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);
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.
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.
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
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....
There are still things that can be changed:
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?FringeQuadEntrance
integer flag?).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…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.
- 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 entireDipole
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
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.
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?
@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.
@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 ?
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?
@simoneliuzzo : Strange indeed
ExactDrift
and ExactMultipole
did not change at allExactSectorBend
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 ?
@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 .)
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?
@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…
@simoneliuzzo : a question about your script: in
cd(['./' atfolder ])
system(['git checkout ' branch]);
cd('..');
git checkout
is unable the make a new clone (no reference to the remote repository). You must use git clone
,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
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.
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:
FieldScaling
attribute for radiation tapering. Disabled unless there is a FieldScaling
in your magnets.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 modificationsCan 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.
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
@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,…)
Documentation is indeed on the right track, to be further developed in separate PRs, for me this is fine
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
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
@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:
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).
Dear @lfarv,
indeed for FCC the change due to exact integrators originates in drifts and quads at the IP.
best regards simone
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.
Same is true for ExactRectBendPass. ExactSectorBendPass instead runs ok.
New integrators for drifts and straight multipoles.