cavity in stl: fix for non-unity charge particles (ions).

[aoeftiger]

For particles with charge != 1 (q0!=1), the cavity kick needs to properly take into account the charge -- this is fixed with this patch.

Comparison notebooks to see the effect, observe cell #35 in all of these cases: the tracking is set up such that in the bucket centre the particles should complete one linear synchrotron period (Qs = 1e-3 and n_turns = 1024):

case (1) reference: proton tracking (which worked before this commit already):

case (2) buggy ion tracking before this patch:

case (3) fixed ion tracking:

[rdemaria]

It is a matter of conventions. Voltage can be interpreted as 1) the integrated electric field (this PR) or 2) the integrated energy change (present implementation). 1) is probably the most straightforward, although one has to remember that for magnetic elements the strength is normalized with p/q. I would approve it but we need to change also pysixtrack. I guess that 1) is also mad-x convention, can you confirm? This would be another point in favor of 1)

[aoeftiger]

I'd prefer (1) as the engineering perspective on the lattice: the cavity would not know what type of particle is going through. It seems more intuitive, in particular if SixTrackLib is really supposed to support different types of particles: what kind of real cavity would ensure the same energy increase for mixed particle chi (charge to mass ratio) values? This would make multi-species beam simulations (e.g. with stripping) quite cumbersome for realistic cavity action -- isn't this one of the goals of supporting chi and qratio etc per particle?

I already prepared the same update in PySixTrack, I'll file the PR. I'm not sure (1) is MAD-X convention, yet there are a lot of MAD-X conventions which SixTrack(Lib) break in favour of the more intuitive and engineering version (e.g. standard HEP eV based unit conventions vs. MeV, GeV mixtures). Up to the holders of general STL wisdom (you!) to decide ;-)

[rdemaria]

I checked mad that seems to use convention 1). If we change the convention we should also change the madx converter in pysixtrack. Have you started from a madx file for creating a lattice?

[aoeftiger]

Yes, I do use the MAD-X conversion. Do I understand correctly that if both codes use convention (1), we don't need to change anything? For the moment, I put the total physical voltage on the cavity in MAD-X and obtain the correct result with SixTrackLib tracking if I use the present PR here.

[rdemaria]

Yes, it does not make much sense. I would have expected the physics to be the same without this PR. Can you verify on a simple sequence of just one cavity?

[rdemaria]

We checked madx and we confirm that the behaviour was consistent between madx and sixtracklib/pysixtrack before the PR (convention 2 energy change). See example:

cav: rfcavity, volt=10, lag=0.25;
ss: line=(cav);
beam,charge=13,energy=1;
use,sequence=ss;
twiss,betx=1,bety=1;
value,table(twiss,ss,pt);

On the other hand SixTrack is using convention 1). Therefore I believe there is still a problem in the lattice scripts, because if we switch to convention 1) then we need to change also the converter. Can you confirm?

[aoeftiger]

Wouldn't this make the cavity translation depend on the beam quantities in the converter? I think I have now seen both uses in MAD-X by convention (due to circumstances..): a) adapting the charge declared in beam in order to get the cavity work according to convention (1) and b) having the usual particle charge in the beam declaration but rescaling cavity energy to particle charge. One rescaling in MAD-X is needed starting from the physical rf voltage in the design report ;)

Due to the fact that people's scripts either use a) or b), it will be difficult to set up SixTrackLib from a MAD-X lattice without additionally providing the beam definition (which would make the converter more complex). So we're left with the follow-up decision:

1. leave the converter as is, which only works correctly for a)
2. let the converter also take the MAD-X beam declaration on top, to avoid rescaling problems (compatible with both a and b, but the infrastructure becomes more complex)

As for the SIS18 lattice in the examples, right now it runs for protons anyway (plus there is no cavity), so this problem does not occur. [Once I'm done with the errors in SIS100, I could add it as an example for higher-charged ions plus alignment and multipole error handling in SixTrackLib..]

[aoeftiger]

PS, there's the corresponding PySixTrack change for convention 1) in https://github.com/rdemaria/pysixtrack/pull/26

[aoeftiger]

I've redirected the analogous PR for PySixTrack to the new main repo, https://github.com/SixTrack/pysixtrack/pull/16 .