Collective effects future developments

[swhite2401]

Hello @lcarver @TeresiaOlsson
Since your are the only 2 known pyAT users for collective effects I would like to start a discussion on what would be needed/useful in the future regarding collective effects, on my side I have:
-RFMODE that was already discussed
-IBS
-Ions (it was mentioned during the working that we could use mbtrack development for this)
-Realistic feedbacks

Any other ideas?

[TeresiaOlsson]

Hi @swhite2401
I think a discussion with the developers of mbtrack2 at Soleil would be very useful. They have implemented a lot of things that might be easy to copy into pyAT. At the moment I have the following things in addition to what you have:

• Option to input impedance instead of wake. In elegant there is both impedance and wake elements and the user can choose which one to use depending on what they prefer. In some cases I found impedance to be a better option and also faster (at least for the elegant implementation). It has also been very useful for checking that the tracking results make sense.
• The possibility to simulate more than one beam, e.g. like one low charge injected bunch together with a stored multibunch beam for injection studies with wakefields.
• Bunch-by-bunch feedback
• Power feedback, i.e. the feedback that detunes the cavity as the beam loading changes with current to minimize the reflected power. I haven't seen any code which has this feedback but there are user cases for simulating the accumulation together with a harmonic cavity.
• Booster transmission with wakefields. For this the charge of the beam needs to change as you loose particles.

Then @lcarver has started to add related tools like the Haissinski solver which I think is really great. Tools like that are very useful to understanding the tracking results and if they come with pyAT the user can use them without having to first convert the input files between code conventions. I'm now wondering if perhaps adding a Vlasov solver could be useful for TMCI and head-tail modes? I'm interested in testing the one called DELPHI they have at CERN, but I haven't had time to look into it yet.

[lcarver]

After my presentation at the AT Workshop @lnadolski also mentioned that it would be good to make use of each others work, specifically referring to the ion effects implementations that are in mbtrack2. In general, I am in favour of these kinds of things, but probably we would need to discuss exactly how it should be handled, (do we write wrappers for an interface between pyat and mbtrack2 (a bit dirty but means we can benefit from developments on the mbtrack2 side), or we do copy the code and modify it to ensure it works on our side (cleaner implementation but we don't benefit from improvements)).

On my side, I would like to be able to generate a matched beam to the longitudinal bucket including impedance sources. In a way, this is what SCALLOPS is doing (a haissinski solver that I am using), for the single bunch case it would certainly work, but to do it cleanly and properly is a bit of work. I know they have this feature in BLonD so I plan to take a look at that at some point and see what can be extracted.

To mention @TeresiaOlsson s points.

1. I think having impedance as input is something we should strongly consider. I'm sure in some certain conditions that it could be faster than time domain.
2. I have been very interested in doing a full simulation of injection efficiency with a stored beam and a distributed wake with a full lattice for some time. Consider it a dream, that at some point we reach the point where the time taken for the simulation is good enough. So for sure this development should be on the list.
3. I think @swhite2401 has something for the bunch by bunch feedback. But in general I think we should really take this opportunity to consider what we want in terms of feedbacks. I was googling around and found some slides from Jani Komppula (who was working on TFB models for PyHEADTAIL) and I see e.g. slide 28: https://indico.cern.ch/event/735184/contributions/3032237/attachments/1668727/2676169/Multibunch_pyheadtail_algorithms.pdf and wonder if we can implement something similar? Is it even needed or is it complete overkill?

I have used DELPHI but only as a beginner user, basically I received a working script and impedance model and ran it changing a couple of numbers, nothing too big. I know that David Amorim (former colleague from CERN but then he went to SOLEIL, maybe he's still there?) did a lot of work with some DELPHI developments so if he is now light source inclined he could be a good person to talk to to see how best to start it.

[TeresiaOlsson]

I think copy code is safer than wrappers, but the even better solution would be to interest the people working on mbtrack2 to work on pyAT ;) I will email Alexis at Soleil and hear what their future plans are and if they might be interested in pyAT.

[swhite2401]

This all sounds very good, indeed for the feedback I have something but I would like to look into this in a more general way: to model a realistic feedback the actuator needs to have access to an observable that belongs to another element (for example kicker in one cell, BPM in another cell) this is for the moment not possible in AT but I have some ideas to propose... let's see when I can find some time to look into this

For the stuff that require less development and that could be implemented in the short term:
-Feedback with actuator and observation point in the same location
-Cavity power feedback
-Scale current with number of particle

[TeresiaOlsson]

In the meantime I will benchmark the current implementation of the feedback against the other codes. I will let you know when I have finished it. I also want to better understand how to set filter coefficients for the realistic feedback. Ideally, I think pyAT should come with a function to set the filter coefficients for your specific machine since that's currently the largest threshold for anyone who wants to simulate harmonic cavities in elegant.