-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use the ct coordinate in the variable multipole pass method #532
Conversation
…SINE option. Bug corrected in the mex function.
Looks ok to me, did you check that the sign was right? |
if(mode==0){ | ||
for(i=0;i<maxorder+1;i++){ | ||
pola[i]=get_pol(ElemA, ramps, mode, t+r6[5]/C0, turn, seed, i, periodic); | ||
polb[i]=get_pol(ElemB, ramps, mode, t+r6[5]/C0, turn, seed, i, periodic); | ||
}; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 β0 into account, so one just needs in the particle loop:
double tpart = t+r6[5]/beta0/C0;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we include the fifth coordinate of each particle for the computation of beta?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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 (β0). So for a cavity at position s, one must subtract s/β0/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:
- Non-relativistic tracking is not yet working,
- I think we are dealing with low frequencies, and very small phase errors should not mater too much,
- 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.
I used the same sign used in RFCavityPass, so I think it is correct.
You are right. Are you doing it or I do it? I missed the introduction of Param->rest_energy! |
@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. |
* thread rng in BndMPoleSymplectic4QuantPass and StrMPoleSymplectic4QuantPass * clang-format * updated QuantDiffPass * small fixes * cleanup of rng functions * updated from #532
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.