Use the ct coordinate in the variable multipole pass method

[carmignani]

The ct coordinate is now used to compute the variable multipole field when we use the SINE option.
Some check_error() were missing in the trackFunction and in the mexFunction.
A bug has been corrected in the mexFunction.

[swhite2401]

Looks ok to me, did you check that the sign was right?

[lfarv]

I would move the time computation out of the order loop:

            if(mode==0){
                 double tpart = t+r6[5]/C0;
                 for(i=0;i<maxorder+1;i++){
                     pola[i]=get_pol(ElemA, ramps, mode, tpart, turn, seed, i, periodic);
                     polb[i]=get_pol(ElemB, ramps, mode, tpart, turn, seed, i, periodic);
                 };
             };

And I think the sign is right.

[lfarv]

To be rigorous and anticipate non-relativistic tracking, one would need at entry to the function:

    double beta0;
    if (Param->rest_energy == 0.0) {
        beta0 = 1.0;
    }
    else {
        double gamma0 = Param->energy/Param->rest_energy;
        double betagamma0 = sqrt(gamma0*gamma0 - 1.0);
        beta0 = betagamma0/gamma0;
    }

Param->T0 already takes β₀ into account, so one just needs in the particle loop:

   double tpart = t+r6[5]/beta0/C0;

[carmignani]

Shouldn't we include the fifth coordinate of each particle for the computation of beta?

[lfarv]

@carmignani : you are right. In the non-relativistic_tracking branch, there is an modified RFCavityPass, which uses

    double betgami = betagamma0*(1.0 + r6[4]);
    double betai = betgami/sqrt(1.0 + betgami*betgami);
    double tau_rel = (r6[5]-el->TimeLag)/betai/C0;

This is almost correct. Correct for a cavity a position 0. But there is still a pending problem: cavities along the ring are synchronised with the reference particle (β₀). So for a cavity at position s, one must subtract s/β₀/C0 from the "absolute" time. For a particle with β_i, in addition to the delay resulting from its path lengthening, one should add the time difference from coming for the origin to the cavity. I have not verified this and stopped working on non-relativistic tracking for some time.

So for now, I would say:

1. Non-relativistic tracking is not yet working,
2. I think we are dealing with low frequencies, and very small phase errors should not mater too much,
3. For this element, there is not the same phasing condition related to the s position as for accelerating cavities.

So go on as it is (even possibly skipping the beta0 correction), we'll see later.

[carmignani]

Looks ok to me, did you check that the sign was right?

I used the same sign used in RFCavityPass, so I think it is correct.

I would move the time computation out of the order loop

You are right. Are you doing it or I do it?

I missed the introduction of Param->rest_energy!

[lfarv]

@carmignani : Go on, Nicola.

For info: the whole infrastructure for non-relativistic tracking is there, but I have problems with RFCavityPass, so non-relativistic tracking does not work yet… However better keeping this in mind.