Haissinski solver for short range wake #361
Conversation
|
Can now be reviewed. |
|
Sorry, @lcarver, I thought that since the wake components in the wake element were just a redistribution of the components of the wake object, they could be considered as "private". if needed, they could be retrieved from the wake object itself. But it appears that they are needed from the wake element, so you should make them public again. Or safer, add properties to extract them (read-only). Adding properties avoid problems with setting the wakes, and does not require modifying the C passmethod! |
pyat/at/collective/Haissinski.py
Outdated
| envelpars = envelope_parameters(ring.radiation_on(copy=True)) | ||
| self.f_s = envelpars.f_s | ||
| self.nu_s = self.f_s / (clight/self.circumference) | ||
| self.sigma_e = envelpars.sigma_e * self.energy | ||
| self.sigma_l = envelpars.sigma_l |
There was a problem hiding this comment.
f_s, sigma_e and sigma_l are available in radiation_parameters (analytically computed), which does not need to turn radiation on.
pyat/at/collective/Haissinski.py
Outdated
| self.eta = get_mcf(ring.radiation_off(copy=True)) | ||
| self.ga = self.energy/e_mass | ||
| self.betrel = numpy.sqrt(1.0-1.0/self.ga/self.ga) |
There was a problem hiding this comment.
self.eta = ring.radiation_off(copy=True).slip_factor
self.ga = ring.gamma
self.betrel = ring.beta
|
@lcarver: Why do you use for input a lattice element (wake_elem)? This objet is not related at all to tracking, so the logical input should be a wake object rather that a lattice element, don't you think? |
|
@lcarver, I tend to agree with @lfarv I will nevertheless need to be able to modify the wake components on the fly (tuning loop of cavity with beam loading -> resonator frequency needs to change) so I will integrate these properties as suggested in a future PR |
|
I understand your points but I was trying to be more efficient by using the LongResonatorElement function which does everything for me in few lines. I agree that the Element is only used for tracking, which this is not doing, so it can be changed. But I wonder if it should be made to work with either wake_object and wake_element. |
|
@lcarver : if you want one-line functions to generate simple Wake objects, you can create factory functions, implemented as static methods of the Wake object, for instance: |
|
@lcarver and @swhite2401 : I think that factory functions are more appropriate than a too sophisticated constructor. Now or later, it's as you like! |
|
So how should I proceed? I propose that we merge this PR (after I make the modifs proposed above by @lfarv ) as it is as there are no issues with the Haissinski part of the code, and I will make a new PR with the modifications to the wake object (for the static functions) and also to allow safe access of the wake components of the wake object. |
|
@lcarver: for me, ok as you propose. |
|
As a comment, the f_s computed from radiation_parameters is slightly different (lower by 5Hz) the f_s computed from envelope_parameters. |
Short range wake solver. Example file using esrf.m from machine_data is also included.
One thing that needs to be done: The paper the equations are based on use -s notation for the wake. This is taken into account for the input but not the output. Needs to be done cleanly so as to avoid issues.
Also if you want a distribution for a high current, it may not converge from a gaussian as it may be too different. I need to add the ability to solve the distribution in current steps.