Multibunch Beamloading #516

swhite2401 · 2022-11-15T09:49:09Z

The multi-bunch beam loading is introduced. Several additions are present in this PR:

a passmethod RFCavityBeamloadingPass.c extenting the functionalities proposed in Cavity with beam loading #191 with multibunch, MPI, a 2 energy loss calculation methods
a python interface for element creation and adding/removing beamloading from cavities
adaptation of examples and minor modifications of the collective subpackage and lattice_object.py
Examples are updated

The proposed strategy is to modify the cavity elements in-place to integrate the beam loading, all the calculations are the done in the C tracking engine. Similarly beam loading can be removed from cavities.
The energy loss in the cavity can be calculated using the phasor method or the wake function, both are compatible with MPI and multibunch tracking.
A feedback loop is integrated and can be tuned using the *Gain arguments, this allows to maintain the effective voltage and cavity phase constant using the tuning angle and generator amplitude regardless of the beam induced voltage. This feedback is presently ideal but can be further extended to integrate more realistic circuits.

This implementation was benchmarked using mbtrack and theory.

…modifs.

…mloading

lfarv · 2022-11-18T17:11:20Z

pyat/at/lattice/lattice_object.py

+        for e in self:
+            if e.is_collective:
+                e.clear_history(ring=self)


This assumes that all Collective elements have a clear_history() method. This could be enforced by adding an @abstact_method to the Collective class. I propose an another PR for that, this one is large enough!

Right! Maybe put an issue as a reminder? Or we just add it here it is a small addition

As you like !

lfarv · 2022-11-18T17:18:36Z

@swhite2401 and @carmignani : could you both confirm that this PR supersedes #191, and that that #191 could be closed?

lfarv · 2022-11-18T17:22:43Z

About remove mail adresses from C files: it would have been preferable to do this in another PR: you are mixing different things and increasing a lot the number of modified files ! For now, keep it here, of course!

pyat/at/collective/beam_loading.py

lfarv · 2022-11-19T14:15:39Z

atmat/attests/pytests.m

@@ -90,7 +90,7 @@ function orbit6(testCase,lat2)
            porbit6=double(porbit6)';
            % Matlab
            [~,morbit6]=findorbit6(lattice.m);
-            testCase.verifyEqual(morbit6,porbit6,AbsTol=1.E-15 );
+            testCase.verifyEqual(morbit6,porbit6,AbsTol=5.E-15 );


Did anything changed in the computation of the closed orbit? Do you get problems with the previous value?
I don't care about 1 or 5 e-15, but that may indicate that something unexpectedly changed…

I did not change anything but the matlab test was systematically failing so I just matched the tolerance of the matlab test to the one of the python test.

Failing on GitHub ? It still succeeds on the other branches, so it looks strange…

So there is one thing. energy_loss.py was changed and is used to determine the initial condition for find_orbit6. This could have an impact on the final result to that level no?

Ok, that could be an explanation. Do you confirm that it fails on GitHub (which platform?), because it still works for me (MacOS).

I found the last failure in the GitHub history: it failed on ubuntu-latest, with an error of 3.2e-15 instead of 1e-15. We don't have the results on the other platforms because all runs are cancelled as soon as one fails.

So let's assume energy_loss.py is the reason for the change.

The matlab tests fail on GitHub, I could not install the matlabengine in my pyenv, either it complains about the matlab version or the python version so I gave up.

swhite2401 · 2022-11-21T09:07:42Z

@swhite2401 and @carmignani : could you both confirm that this PR supersedes #191, and that that #191 could be closed?

All the functionalities of #191 are integrated in this one, so yes it can be closed

swhite2401 · 2022-11-21T09:08:43Z

About remove mail adresses from C files: it would have been preferable to do this in another PR: you are mixing different things and increasing a lot the number of modified files ! For now, keep it here, of course!

Yes sorry, I realized after that this was a bit bold...anyway now it is done

…into beamloading_iterative

lfarv · 2022-11-22T13:03:16Z

@swhite2401 : another question: why do you implement you own turn counter in the integrator? This prevents you from stopping/restarting the tracking, and it may lead to different turn numbers depending on the integrator.

Also, by relying upon the "standard" turn counter, you could clear the turn history on turn zero in the integrator, avoiding the Lattice.set_wake_turnhistory. Well, this would either be a rewriting in C or a call to python from C, so it may not be a good idea…

swhite2401 · 2022-11-22T13:59:07Z

@swhite2401 : another question: why do you implement you own turn counter in the integrator? This prevents you from stopping/restarting the tracking, and it may lead to different turn numbers depending on the integrator.

Also, by relying upon the "standard" turn counter, you could clear the turn history on turn zero in the integrator, avoiding the Lattice.set_wake_turnhistory. Well, this would either be a rewriting in C or a call to python from C, so it may not be a good idea…

Well, I was facing issues with memory allocation. The length of the position and size vector are fixing in lattice_pass bu the argument nturn, if you restart the tracking from turn n you have to modify this length and then the keep_lattice option cannot be used.
I made the assumption that the user going out of the C tracking engine would fetch the data, and then restarting the tracking would be equivalent to acquiring a new data set... this may not be optimal.
You have any suggestions?

Concerning the clear history, you may not necessarily want to clear it for a new tracking...maybe the oppsoite in fact to start from steady state. For me it is more relevant when you change beam parameters like the fillpattern and the history is clearly not valid anymore

lcarver · 2022-11-23T10:16:32Z

So I have already approved these changes. but I did some further tests following comments from @carmignani and @lfarv. Below are some quick plots showing some expected effects.

992 bunches with single particles. Ib=200mA. I kick one bunch and get the incoherent tune and I kick all bunches and get the coherent tune. This is as expected.

I tried the same with a single bunch at 200mA. Now I try to kick one particle within the bunch for the incoherent and kick the full bunch for the coherent. This was trickier to simulate, I needed Nslice=50 and I had a big problem with not having enough turns to sufficiently sample the frequency I was trying to find. Strong kicks were needed, but eventually this could be simulated. However this is not a realistic case so it is good that it works as expected but it will not come up in regular use.

I also did a check to see if we observe any transient beam loading effects. I did 496 bunches with 1 macro particle per bunch.
I see a shift in the synchronous position of each bunch which is expected. The vgen is computed assuming the mean vbeam of all bunches, but the vbunch is now different for each bunch. This is what happens in reality, and is a nice check that everything is working well, which it is.

lfarv · 2022-11-24T08:16:27Z

@lcarver : thanks for the checks: very nice, it's convincing!

swhite2401 and others added 30 commits January 31, 2022 11:12

intermediate

b3a7806

bl elements class

d5cd77a

modify ring in place

61dc8da

Added example file for beamloading implementation

24a5170

tuning

71619e4

intermediate

5c89d91

introduce setters

957337f

Merge branch 'master' into wake_factory_methods

d540dd8

make generic build private

a222954

changed names

e996642

changed names

5a72c25

Fixed bugs. Adapted haissinski and examples for use with wake_object …

f5ef816

…modifs.

allow multiple wake components

0d4c79c

Merge branch 'beamloading' of https://github.com/atcollab/at into bea…

f7a845c

…mloading

resolve conflicts

ff14da5

resolve conflicts

daa7c3f

Merge branch 'wake_factory_methods' into beamloading

0af0b50

use wake func

741e38b

update

8e97fec

pep8

6208515

case of examples

ac4d442

remove beamloading example

db28ee1

Merge branch 'wake_factory_methods' into beamloading

415778b

fix test + zero length zslice bug

3196a7d

added import

fa6bdc2

pep8

a646e5b

handle smin=smax, forbid Zcuts for off-energy tracking

721b4f4

Simplified formula

eb0f55b

Simplified formula

b1beb2e

fix example

e5811ef

Lee Carver added 2 commits November 18, 2022 09:14

Try except not needed

94e64cc

Last correction of example file

5b8f5b1

lcarver approved these changes Nov 18, 2022

View reviewed changes

lfarv reviewed Nov 18, 2022

View reviewed changes

pyat/at/collective/beam_loading.py Outdated Show resolved Hide resolved

lfarv reviewed Nov 18, 2022

View reviewed changes

pyat/at/collective/beam_loading.py Outdated Show resolved Hide resolved

lfarv reviewed Nov 19, 2022

View reviewed changes

swhite2401 added 2 commits November 21, 2022 10:35

set attr shape, remove unused imports

9306798

Merge branch 'beamloading_iterative' of https://github.com/atcollab/at …

74e0ca7

…into beamloading_iterative

lfarv mentioned this pull request Nov 22, 2022

Beam monitor #521

Merged

use real path length in bunch_spos

ae7d2a6

swhite2401 added 4 commits November 22, 2022 15:53

use analytical ct drift

051a582

bugfix

93c397e

add abstract method clear_history in Collective

a3bc32e

optional clear history on current change

95f444f

lfarv approved these changes Nov 24, 2022

View reviewed changes

This was referenced Nov 24, 2022

Unfold beam #524

Merged

Cavity with beam loading #191

Closed

Merge branch 'master' into beamloading_iterative

69cef23

swhite2401 merged commit 63d0e34 into master Nov 28, 2022

swhite2401 deleted the beamloading_iterative branch November 28, 2022 09:24

lfarv mentioned this pull request Jun 7, 2023

Release 0.4.0 #616

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Multibunch Beamloading #516

Multibunch Beamloading #516

swhite2401 commented Nov 15, 2022

lfarv Nov 18, 2022

swhite2401 Nov 21, 2022

lfarv Nov 21, 2022

lfarv commented Nov 18, 2022

lfarv commented Nov 18, 2022 •

edited

lfarv Nov 19, 2022 •

edited

swhite2401 Nov 21, 2022

lfarv Nov 21, 2022

swhite2401 Nov 21, 2022

lfarv Nov 21, 2022

lfarv Nov 22, 2022

swhite2401 Nov 22, 2022

swhite2401 commented Nov 21, 2022

swhite2401 commented Nov 21, 2022

lfarv commented Nov 22, 2022

swhite2401 commented Nov 22, 2022

lcarver commented Nov 23, 2022 •

edited

lfarv commented Nov 24, 2022

Multibunch Beamloading #516

Multibunch Beamloading #516

Conversation

swhite2401 commented Nov 15, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lfarv commented Nov 18, 2022

lfarv commented Nov 18, 2022 • edited

lfarv Nov 19, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

swhite2401 commented Nov 21, 2022

swhite2401 commented Nov 21, 2022

lfarv commented Nov 22, 2022

swhite2401 commented Nov 22, 2022

lcarver commented Nov 23, 2022 • edited

lfarv commented Nov 24, 2022

lfarv commented Nov 18, 2022 •

edited

lfarv Nov 19, 2022 •

edited

lcarver commented Nov 23, 2022 •

edited