RFDF matrix
Moderators: michael_borland, soliday
-
- Posts: 1959
- Joined: 19 May 2008, 09:33
- Location: Argonne National Laboratory
- Contact:
RFDF matrix
In version 24.0, we added a matrix for the RFDF element (a type of transverse deflecting cavity). Unfortunately, the STANDING_WAVE parameter is ignored in computing the matrix. The computed matrix is valid for a standing wave cavity, so if STANDING_WAVE=0, the wrong matrix is returned. The STANDING_WAVE parameter is properly handled for tracking.
This will be fixed in the next release. For those who build from source, a corrected source file is attached.
--Michael
This will be fixed in the next release. For those who build from source, a corrected source file is attached.
--Michael
- Attachments
-
- compute_matrices.c
- (68.28 KiB) Downloaded 1429 times
-
- Posts: 1959
- Joined: 19 May 2008, 09:33
- Location: Argonne National Laboratory
- Contact:
Re: RFDF matrix
This bug was fixed in version 24.1
--Michael
--Michael
-
- Posts: 83
- Joined: 20 Aug 2008, 13:18
- Location: Northern Illinois University & Argonne National Laboratory
- Contact:
Re: RFDF matrix
All,
I would like to model a thin-lens deflecting mode cavity.
If I set L=0 in the RFDF element and inspect the matrix provided by runin the testrfdf.ele command file, I get the usual think-lens matrix for a deflecting mode cavity (TM110).
I inserted this matrix into a beamline and ran comprfdrMAT.ele, I also did tracking using the RFDF element (see comprfdf.ele) the results are different and I cannot understand why; see runTEST script.
I saw there were issue with a previous version of elegant and I am using elegant V24.1 (darwin-x86 version of Oct. 6, 2011).
Thanks for any help. -- Philippe.
PS: all my files/scripts are attached.
I would like to model a thin-lens deflecting mode cavity.
If I set L=0 in the RFDF element and inspect the matrix provided by runin the testrfdf.ele command file, I get the usual think-lens matrix for a deflecting mode cavity (TM110).
I inserted this matrix into a beamline and ran comprfdrMAT.ele, I also did tracking using the RFDF element (see comprfdf.ele) the results are different and I cannot understand why; see runTEST script.
I saw there were issue with a previous version of elegant and I am using elegant V24.1 (darwin-x86 version of Oct. 6, 2011).
Thanks for any help. -- Philippe.
PS: all my files/scripts are attached.
- Attachments
-
- testRFDF.tar
- (90 KiB) Downloaded 628 times
-
- Posts: 1959
- Joined: 19 May 2008, 09:33
- Location: Argonne National Laboratory
- Contact:
Re: RFDF matrix
Philippe,
I don't entirely understand what's going on here, but a workaround is to put a CENTER element in front of the MATR element.
CT: center,t=1
--Michael
I don't entirely understand what's going on here, but a workaround is to put a CENTER element in front of the MATR element.
CT: center,t=1
--Michael
-
- Posts: 83
- Joined: 20 Aug 2008, 13:18
- Location: Northern Illinois University & Argonne National Laboratory
- Contact:
Re: RFDF matrix
Michael,
I think there is still an issue. I added the center element (before and after my MATR element) and although the rms properties seem to agree the longitudinal phase space have discrepancies (I am looking at sddsplot -column=t,p com*.out -graph=dot,vary -mode=x=center in the files I sent yesterday).
Thank you,
-- Philippe.
I think there is still an issue. I added the center element (before and after my MATR element) and although the rms properties seem to agree the longitudinal phase space have discrepancies (I am looking at sddsplot -column=t,p com*.out -graph=dot,vary -mode=x=center in the files I sent yesterday).
Thank you,
-- Philippe.
-
- Posts: 83
- Joined: 20 Aug 2008, 13:18
- Location: Northern Illinois University & Argonne National Laboratory
- Contact:
Re: RFDF matrix
Michael,
I am now pretty sure the RFDF is the problem. Again I am tracking to first order with L=0 so that the RFDF should behave as a thin lens. In this case the beamline I attached in my post of yesterday should perfectly exchange the longitudinal and horizontal emittances. It does not while it does when I use the MATR element to model the deflecting cavity.
The main reason I want to switch to the RFDF instead of using MATR is that I cannot do backtracking with a MATR elements (we had discussion on this forum regarding this issue -- I am going to post an update on this one...).
The script I use to compare the emittance is attached. It usage is plot_all_emit FileName Offset . Thank you,
-- Philippe.
I am now pretty sure the RFDF is the problem. Again I am tracking to first order with L=0 so that the RFDF should behave as a thin lens. In this case the beamline I attached in my post of yesterday should perfectly exchange the longitudinal and horizontal emittances. It does not while it does when I use the MATR element to model the deflecting cavity.
The main reason I want to switch to the RFDF instead of using MATR is that I cannot do backtracking with a MATR elements (we had discussion on this forum regarding this issue -- I am going to post an update on this one...).
The script I use to compare the emittance is attached. It usage is plot_all_emit FileName Offset . Thank you,
-- Philippe.
- Attachments
-
- plot_all_emit.gz
- (302 Bytes) Downloaded 352 times
-
- Posts: 1959
- Joined: 19 May 2008, 09:33
- Location: Argonne National Laboratory
- Contact:
Re: RFDF matrix
Philippe,
I think the main problem is with the matrix. I realize that the matrix was produced by elegant, but it turns out that it isn't quite right when the beam energy is very low. It needs a factor of 1/beta in the R25 and R61 elements.
I'm still checking to see what other issues there might be.
--Michael
I think the main problem is with the matrix. I realize that the matrix was produced by elegant, but it turns out that it isn't quite right when the beam energy is very low. It needs a factor of 1/beta in the R25 and R61 elements.
I'm still checking to see what other issues there might be.
--Michael
-
- Posts: 1959
- Joined: 19 May 2008, 09:33
- Location: Argonne National Laboratory
- Contact:
Re: RFDF matrix
This has been fixed in release 25.0.2.
--Michael
--Michael