adding wiggler passmethod to integrators

[mashl]

symplectic wiggler passmethod with classic radiation similar to Elegant Cwiggler

[carmignani]

Hello @mashl,
thanks for your contribution! As you can see opening some random passmethods, from AT 2.0 we changed the function used by atpass to enter in the passmethods, from the passfunction to the trackfunction.
The passfunction is still working in matlab AT, but it is not working in python AT, and this is why I think the automatic checks have failed.

[simoneliuzzo]

Hello @mashl,
do you have some image/benchmark showing the tests you did to check that the passmethod works correctly?

[simoneliuzzo]

There is also this issue still open: #1

[willrogers]

In atintegrators/user/ there is already GWigSymplecticPass.c, gwig.c and gwig.h.

@bnash do we know what the user directory is for?

[willrogers]

Also, we should have some documentation on adding an integrator. Is there some documentation already?

[mashl]

Hello @simoneliuzzo
there is a comparison between ILSF bare lattice (lattice 1) and ILSF lattice with 6 undulator

[simoneliuzzo]

Dear @mashl,
could you send also the values obtained for the same lattices in Elegant?
What are the differences with the passmethod indicated by @willrogers in atintegrators/users/GWigSymplecticPass.c

[mashl]

hello @carmignani
as I found out from your comment I have to change below line (change passFunction to trackFunction) to solve auto check error

ExportMode int* passFunction(const mxArray *ElemData, int *FieldNumbers, double *r_in, int num_particles, int mode)
is that what you meant?

[carmignani]

Yes @mashl! The passfunction has to be changed in a trackFunction, then also the mexfunction has to be modified by using the functions in atelem.c.
In the top of the file you also have to define the structure of the element, check for example DriftPass.c

[carmignani]

I agree with @willrogers about the documentation for developers. It was one of the documents started on overleaf by @bnash, if I'm not wrong, but I think there was not much in it.

[willrogers]

Documentation could be in a README in the atintegrators directory.

[mashl]

dear @simoneliuzzo
I add one wiggler ( Ltot=3m , Lw=30 cm, Bmax=2.5 T) to the bare lattice and there are the results from AT and Elegant (twiss output)

[mashl]

@simoneliuzzo @willrogers
and about the differences between new Gsymplecticpass.c and the old one I only add the E0 to wiggler Elemdata and read this from Wiggler structure because the code couldn't read the energy from GLOBVAL (at least in my AT)
actually the new passmethod is GWigSymplecticRadPass.c that take the radiation into account. Since the elements with radiation have two passmethods, I have distinguished these two from each other.

[simoneliuzzo]

Dear @mashl,
the values in the elegant file do not seem to be identical to those given by the modified AT pass method (for example: ex0_Elegant=252pm, ex0_AT=226pm, same for U0 vs dE/turn) . Did you expect this?

[bnash]

@willrogers

In atintegrators/user/ there is already GWigSymplecticPass.c, gwig.c and gwig.h.
@bnash do we know what the user directory is for?

I don't know exactly. We inherited this structure. I guess the idea was to put individual user developed integrators into the user directory. The analytic symplectic integrator for wigglers using the method of Y. Wu and E. Forest (included in gwig.c) (see paper) have been thought to require a bit more work to get working properly, so was separated out from the others.

[mashl]

Dear @simoneliuzzo
The differences between U0,TauX,TauY values in Elegant and AT are less than %1 that means I_2 and I_4 integrals are calculated correctly. I have to double check the I_5 integral calculation process because I think that it is the main factor behind this disagreement. thank you for your helpful comments
I will work on this

[bnash]

Hello @mashl, thanks so much for this contribution. That would be great to be able to include radiation properly with insertion device modeling.

If the damping times between AT and Elegant are coming out the same, and the emittances are not, then I guess this means the diffusion is different. By changing the passmethod, you can get the damping right, but you can't get the diffusion right unless you edit the diffusion matrix computation in the Ohmi Envelope calculation. The diffusion matrix computation is here
https://github.com/atcollab/at/blob/master/atmat/atphysics/Radiation/findmpoleraddiffmatrix.c

I wonder if Elegant includes the quantum diffusion from Wigglers correctly in their implementation?

[bnash]

Likewise, for U0, we need to check how that is computed. Normally the function may not know to look in the Wiggler pass method to find some additional energy loss.

[carmignani]

@bnash, I think @mashl is not using ohmienvelope for his emittance computation, but a modified version of ringpara, where he computes the radiation integrals.

[bnash]

@carmignani @mashl Ok, then one has to make sure that the wiggler is included in the radiation integrals.

When I get a chance, I will try this pass method.

[mashl]

Dear @bnash
thanks for your support, @carmignani says right. I used the [Cnm Kx Ky Kz Thetaz] polynomial and defined the By(z) function for horizontal wiggler (same for vertical and elliptical) . By using this function and Rung-Kutta 4th order method the horizontal dispersion through the wiggler is calculated. So I have 1/rho , 1/rho^2 and eta_x through the wiggler and by using the numerical integration method (trapezoid) I calculated the I_1 to I_4 integrals value. the results that depend on this integrals have a good agreement with elegant. But I used some approximation for calculating the H(x) for I_5 integral and I think that's the source of difference between Elegant and AT emittance.

[mashl]

@bnash @carmignani @simoneliuzzo
To ensure the accuracy of the results, I turn on the radiation for all elements (using
'Gwigsymplecticradpass' for wiggler) and use the R_OUT(5)*
to calculate the U0 , the difference between theoretical U0 and U0 from tracking is less than %0.1.
*[ROUT=linepass(ring2,[0 0 0 0 0 0]'); U00=-ROUT(5)*energy;]

[ZeusMarti]

Dear All,

We did a similar thing for AT1.3 (sorry, our student started with the old version and he has done most of the development on AT1.3, in the future I think we will try to develop for AT2.0). He used the AT formula for dH/dl which converges with much less slices than the Elegant version. Instead of:

dFactor = ((1+X[4])*(1+X[4]));

(line 468 of your gwigR.c), in our code we used:

SQR(1+X[4])*(1 + X[0]irho + 0.5e0(SQR(X[1])+SQR(X[3]))/SQR(1+X[4]))

Regarding the emittance calculations, we are also trying to make the omhienvelope method to work for this pass method. Our student has done some preliminary tests with a modified version of findmpoleraddifmatrix, but so far we do not get a good agreement with the Sands integrals method...

Unfortunatelly our student will leave soon, we will try to continue his work. In any case, we are open to anyone who wants to collaborate (I already contacted Ahmad)!

Best,

Zeus

[mashl]

Dear all
In the previous comparison between Elegant and AT results, there was a significant difference between emittances. After re-calculating, it turned out that the problem was I5 integral. After the problem was resolved, a comparison was made again and this time the results were in a good agreement with each other. Is there another test to ensure that the results are correct?

[simoneliuzzo]

Then also the modified ringpara should be changed and committed in your forked version of AT2.0 such that we may try to get the same results for testing .

[willrogers]

Is I4 correct?

[mashl]

dear @willrogers
I forgot to type e-1 in the end of I4 (for elegant) the exact value is -1.354852e-01

[mashl]

dear @simoneliuzzo
I will change the functions in my fork

[carmignani]

Hello @mashl,
I see in your table that some basic quantities are not exactly the same when computed with AT and Elegant, like for example the tunes. Are these small disagreements due to the wiggler element or your original lattices have already slightly different tunes? I think in general we can have perfect agreement on the linear lattice between AT and Elegant.

[mashl]

Dear @carmignani
Thanks for your comment; I have faced with a miscalculation of lattice length, which led to the change in phase advance and tunes. Here is the comparison between Elegant and AT for bare lattice and lattice with ID.

[mashl]

Dear @simoneliuzzo
I added the ringpara to my fork

[simoneliuzzo]

Dear @mashl

we have some converters from AT to Elegant. Could you send me an AT lattice file, I will give it a try (single one) for conversion and ask @carmignani to check some basic values in Elegant. That way we may compare lattices more appropriately and be sure about the correct import of the elegant features.

We do not see in the pull request the ringpara.m file. Did you commit and push it?
by the way, did you modify ringpara.m from the AT2.0 version?

ciao

[simoneliuzzo]

any progress on this topic?

[simoneliuzzo]

@mashl, make sure that you commit all needed changes in the "pull request", that way we may checkout the fork, test it, and eventually approve the pull request (that merges all the modifications to AT directly).
In particular:

• add the pass method
• add the corresponding element creator
• modify ringpara
• merge the AT2.0 master changes to the fork

thank you
ciao
Simone

[mashl]

Dear @simoneliuzzo
all the files are added to my fork but I couldn't merge them to this pull, therefore I create the new pull request.

[willrogers]

Merged in #121 .