Open lfarv opened 4 months ago
The processing of the diffusion matrix requires two things:
For each integration step, one needs to propagate the current diffusion matrix. This requires the 6x6 transfer matrix of each of the elementary steps, computed around the closed orbit. Up to now, the transfer matrix is computed analytically for the following steps:
Still missing for implementing the “exact” bends:
Building the transfer matrix analytically becomes difficult for those: taking the derivatives of E. Forest’s formulae is tedious. It’s possible to build the matrix numerically in the C integrator, but this might be too slow at run time.
For the “radiating” steps, one needs to compute the increment to be added to the propagated diffusion matrix. This is already done for:
Still missing is:
So there is a significant work to provide the “exact” bends. ON the other hand I think that all ingredients are there for the wiggler.
As it is now, this is already better than the present computation: one could redirect the missing (non-upgraded) passmethods to BndMPoleSymplectic4RadPass
, with a result identical to what we have now. But this implies that we keep a hard-coded list of upgraded methods. Otherwise, one can easily check that a passmethod does not modify the diffusion matrix, and in this case revert to BndMPoleSymplectic4RadPass
, but this doubles the processing time…
The hard-coded list avoids that, but it has to be maintained… If you think of another way, let us know.
If this is solved, one could think of merging this as it is, or with the GWigSymplecticPass
, and have a smooth transition while other passmethods are upgraded. Please advise!
This study revealed three problems with the present implementation:
findmpoleraddiffmatrix.c
still uses old physical constants. For comparison with the new method, I had to modify it to use the new ones. Results are then identical to machine precision.I propose to open another pull request to solve points 1 and 3: it will allow vertical bends and make comparisons straightforward. What's your opinion on that?
While the tracking in AT is modular (pass methods may be modified or added easily), the computation of the diffusion matrices used in
ohmi_envelope
is centralised and difficult to maintain.The computation is done in
findmpoleraddiffmatrix.c
for all magnets, straight or curved. Wigglers are ignored. This C function combines the tracking and the computation of diffusion matrices and is based onBnd/StrMPoleSymplectic4RadPass
.This PR is a proof of concept where the computation of diffusion matrices is included as optional in each
*RadPass
passmethod. This allows the computation to be consistent for each tracking variant, and has the following main advantages:Bnd/StrMPoleSymplectic4RadPass
(on-axis, all methods should be equivalent).As an example, in this branch, the following passmethods include the computation of the diffusion matrix:
BndMPoleSymplectic4RadPass
,StrMPoleSymplectic4RadPass
(with strictly identical results as before) andExactMultipoleRadPass
(with a slightly different result for large off-momentum). A new C functiondiffusion_matrix.c
is added to replacefindmpoleraddiffmatrix.c
using the new pass methods while keeping a similar interface.ohmi_envelope
is modified to call this new function, with a test mode allowing to switch easily betweenfindmpoleraddiffmatrix.c
anddiffusion_matrix.c
.This approach will require all
*RadPass
methods to be modified, which is a significant task. As it is now, a non-modified method generates a zero contribution to the diffusion (but still propagates correctly the cumulated matrix): as if the element does not contribute to the emittance.This PR is open to discuss the potential of this method and identify the difficulties before going further on. It follows the discussion in #715 and integrates the proposal of @carmignani (https://github.com/atcollab/at/discussions/715#discussioncomment-8257999) which makes the transition easier.