Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Undulator dipoles #571

Draft
wants to merge 9 commits into
base: master
Choose a base branch
from
Draft

Undulator dipoles #571

wants to merge 9 commits into from

Conversation

simoneliuzzo
Copy link
Contributor

I try to add a method to create an undulator made of dipoles.

an example demo is provided in the pyat/examples/undulators

How to merge such list of elements (that gives the correct emittance and energy loss) with an IdTablePass element?

@oscarxblanco
Copy link
Contributor

Good question @simoneliuzzo ,

I was thinking to use a wiggler element, and did try to use pyat to calculate the radiation integrals with no sucess.
I'll have a look on your example asap.

o

@simoneliuzzo
Copy link
Contributor Author

Thank you @oscarxblanco
there is no urgency, as you see I do not even pass the tests yet!

@simoneliuzzo
Copy link
Contributor Author

@lcarver and @swhite2401 suggested to give the possibility to define an undulator that has both the radiation effects and the kick map effects. However both elements are thick. How to put them together? @oscarxblanco and @lfarv may be have some ideas?

@swhite2401
Copy link
Contributor

Hello @simoneliuzzo do you want me to review this PR?

@simoneliuzzo
Copy link
Contributor Author

simoneliuzzo commented Mar 3, 2023

Dear @swhite2401,
If you want, but it is still a draft.
Basically I uploaded here the functions I prepared for the study of wiggler impact on the EBS.
I look for a way to implement simultaneously the dipole model (giving correct energy loss and emittances) and the kick map.
Both are thick elements, so it is unclear to me how to use them together.
Once we sort this out, I will add the InsertionDeviceKickMap elements to the undulator model, add unit tests, and ask for review.

@simoneliuzzo
Copy link
Contributor Author

Dear @oscarxblanco ,

do you know if we can put 0 length in InsertionDeviceKickMap element?
that may be an easy solution to make the two work together.

thank you
best regards

@oscarxblanco
Copy link
Contributor

@simoneliuzzo It is not possible because Length is divided by 2Nslice in IdTablePass.c (line 56).

I would suggest to create a new element with Length and IntegratedLength.
Length coud be varied as needed for plots, slices and so on.
IntegratedLength is always kept unchanged and passed to the InsertionDeviceKickMap.

That new element should inherit (all or most) properties from InsertionDeviceKickMap.

Best regards,
o

@lfarv
Copy link
Contributor

lfarv commented Mar 9, 2023

Hi all, sorry to come late in the discussion, but I have strong concerns about what you can get out of this model…

The field model that you build with this method is a succession of hard-edge dipoles. This is unrealistic, the field cannot jump from positive to negative so what you simulate has nothing to do with a real undulator field. For standard dipoles, you know that taking into account the fringe field is tricky and uses empirical approximations: see the different methods presently implemented. Usually the fringe field effect is neglected (which is probably sometimes wrong). But an insertion device in only fringe fields, nowhere you'll get a flat top ! The simplest field model for insertion devices is Halbach's field expansion which is used if WiggLinearPass.

field_expansion

With kx2 + kx2 = k2. As you can see, it's rather different from a succession of dipoles. For instance, By(s) is a cosine wave. For a realistic field, you need to combine several harmonics in k.

So now, what you can get from this "dipole" model:

  • contribution to the emittance: it's the only way, as up to now no other method is available. You'll get a largely over-estimated radiated power because of the difference between the square field variation with z, as simulated by dipoles, and the sine wave-like real field, but at least you get something. Do you have a comparison with analytical values for the radiated power?
  • tune shifts should be approximately correct, but again for this you can compare with the analytical value,
  • but NEVER USE THIS MODEL FOR TRACKING, except for very long period devices (few pole wigglers). Your model is 1-dimensional: Bx=0, By=B(z), Bz=0 while the real field is 3-D. The By field is constant along z, while its variation may be responsible for aperture limitations (plus the contributions of Bx and Bz fields). And don't even think of adding multipoles: multiple expansion is valid only for infinitely long magnets…

As a 1st check: could you make a comparison with WiggLinearPass for the same (strong) device ? With a single field harmonic.

The problem with WiggLinearPass is that it is based on a theoretical field model, and real undulator field can be quite different from that. But at least the model satisfies Maxwell's equations, which is not the case of your "dipole" model.

The only correct passmethod for insertion device is "IDTablePass": it's the only way to define a realistic field, in particular the decay of the By field along x, critical for the horizontal aperture. I don't see how you could "combine" dipoles and ID tables: you must forget the dipoles in tracking

I am not an expert in insertion devices, most of what I know comes from discussions with P. Elleaume, who was very suspicious about models based on Halbach's field expansion. You have at ESRF experts in IDs, a discussion of ID field modelling would be very useful to clarify all this!

@simoneliuzzo
Copy link
Contributor Author

Dear @lfarv

I understand and completely agree with your description.

The problem for me is that there is no wiggler or undulator method doing really all that we would like to see from an ID or wiggler pass. IdTablePass and WigglerLinearPass do not give the correct emittance and energy loss. Dipoles model do not give the correct tracking.

This pull request is open simply to point out this rather important missing feature for a code that is used mostly by synchrotron light sources.

I did not intend to merge the methods I have submitted, but only to trigger this discussion (and share the files) to think about what should be done in order to have what we we really need: a method to add to an AT lattice an ID that gives the correct tracking and global parameters.

Concerning the dipole model we recently compared the radiated power computed by the dipole model and the values obtained from formulas and from the control system:

Screenshot 2023-03-10 at 08 47 10

93KeV from the dipoles model, 100KeV from the cavities.

@simoneliuzzo
Copy link
Contributor Author

I am preparing the test with wiggler pass and will share the result as soon as they are ready

@simoneliuzzo
Copy link
Contributor Author

Here a first figure: beta-beating and dispersion deviation with kickmpas (IdTablePass), dipoles, WigglerLinearPass

Screenshot 2023-03-10 at 09 36 41

WigglerLinearPass gives result rather different from IdTablePass and dipole model.
In particular there is no dispersion modulation (invisible inside the element) nor horizontal beta-beating.

Thanks to this figure, I am an even more "confused" user.

@simoneliuzzo
Copy link
Contributor Author

simoneliuzzo commented Mar 10, 2023

I am unable to continue the tests with Wiggler element.

Even if the optics are visible with plot_beta(), at.envelope_parameters gives an error: Unstable Ring.
Screenshot 2023-03-10 at 09 50 21

and the lattice file if you want to try your self.
ring_w150_wiggler_25mm.mat.zip

I now realize that the Wiggler Element does not use WigglerLinearPass but GWigSymplecticPass!
So I have to repeat everything. I try changing the default pass method for a Wiggler element. If it does not work I will give up.

@simoneliuzzo
Copy link
Contributor Author

I switched pass Method for the wiggler element to WiggLinearPass.

now the optics return nan
and the tracking fails with error 'Wiggler' object has no attribute 'InvRho'

So I think that the either the Wiggler element has some problem or I am not using the correct element. Likely the second.
Please advise.

@simoneliuzzo
Copy link
Contributor Author

Lattice with WiggLinearPass element:
ring_WiggLinearPass.mat.zip

@lfarv
Copy link
Contributor

lfarv commented Mar 10, 2023

@simoneliuzzo: I'm sorry, I made a confusion for passmethods: the right one should be GWigSymplecticPass, so your first series of tests was correct, forget WiggLinearPass.

You are talking of a W150 ID. With this long period of 150 mm, you are in a favorable situation for the dipole model ! On the other hand, GWiggSymplectic pass in penalised, because one would need additional 3rd, 5th and more harmonics to describe really the field shape. Then I have a few questions on you results:

  1. Energy loss: both Matlab and python version compute the ID energy loss. With the "integral" method, this uses the analytical formula. What does this give, compared to the 100 keV (cavities), and the 93 keV (dipole model) ? For the dipole model, did you take the peak field to determine the slice bending angle, or a kind of effective field ? I expected a difference opposite to what you get (over-estimation of the dipole model). That's already a 1st surprise.

  2. Beta beating. I'm a bit confused by the number of curves: I'm looking for "dipole model", labeled "dipoles" I guess, "WiggLinearPass", (should be GWiggSymplecticPass) labeled "wiggler" probably, and kick maps: where is it among the other curves ? And what are the disturbing other curves ?
    Do we expect any dispersion modulation from a perfect wiggler ? Normally not. Did you put half slices at the extremities of your dipole sequence ? You should check that when inputing zeros(6) at the input, you get zeros(6) at output. Take care in particular to a possible position offset.

I have other questions, so I'll continue later

@simoneliuzzo
Copy link
Contributor Author

Dear @lfarv, @oscarxblanco, @swhite2401 and @lcarver,

@lcarver noticed that the new passmethod #632 could solve the problem we are discussing here. By adding to the undulator pass also the energy loss field, we may have an undulator model for AT that reproduces both the kickmaps effects and the energy loss per turn.
The energy loss would need to be computed before hand with this solution.

regards
simone

@oscarxblanco oscarxblanco mentioned this pull request Oct 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants