transverse gradient undulator

Moderators: cyao, michael_borland

michael_borland
Posts: 1933
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: transverse gradient undulator

Post by michael_borland » 15 Jun 2017, 07:50

Ji,

I fixed some problems with the script and it should now work for your case.

Please see attached and let me know if problems continue. (I've zipped the file to protect it from the virus scanner.)

Thanks for bringing the bug to my attention.

--Michael
Attachments
computeGeneralizedGradients.zip
(2.35 KiB) Downloaded 513 times

Ji_Li
Posts: 13
Joined: 31 May 2017, 07:16

Re: transverse gradient undulator

Post by Ji_Li » 15 Jun 2017, 09:52

Michael,

Thanks for your reply.

There are still errors with the new script. The following is the error when I run: computeGeneralizedGradients -input field.sdds -output GG -mainHarmonic 2 -nHarmonics 5

warning: (z, Bz) does not appear in GG.ref
1 of 1 datanames absent from file GG.ref
warning: no datanames in request found for file GG.ref
Warning: not all y quantities have the same units

I also used the generated GG.ggrad file for BGGEXP to compare with BMXYZ, the discrepancy is quite large. I don't know what is wrong.

In the zipped file, results_of_computeGeneralizedGradients.png represents the results of running computeGeneralizedGradients, the maximum field is ~0.6 T, but the real maximum By on axis should be ~1T; BGGEXP_RK is the comparison with BMXYZ(runge-kutta) method, the red one is from BGGEXP . And the .lte and .ele files are also attached.

Besides, does the input number of -mainHarmonic make a big difference for tracking results?

Ji
Attachments
RW.zip
(14.15 MiB) Downloaded 483 times

michael_borland
Posts: 1933
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: transverse gradient undulator

Post by michael_borland » 16 Jun 2017, 12:13

Ji,

We are looking into this. Previously, we'd only tried this technique with data for a single period. I didn't appreciate when recommending it that it may not work well with a full-device field.

I'll let you know what we find.

--Michael

michael_borland
Posts: 1933
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: transverse gradient undulator

Post by michael_borland » 19 Jun 2017, 14:52

Ji,

Ok, I think I've fixed it. Please use the attached version.

computeGeneralizedGradients -input field.sdds -output ggExp -mainHarmonic 1 -nHarmonics 5 -allHarmonics 1

The -allHarmonics option tells the script to use all the harmonics above m=1, rather than the usual allowed harmonics for a dipole. In addition, the script now behaves correctly when the data is an antisymmetric function of z. The resulting fit is pretty good, though not perfect.

You'll still see a few warning messages, but that's expected because your input file does not have Bz data, which is used for the plots if it is present.

--Michael
Attachments
computeGeneralizedGradients.zip
(2.79 KiB) Downloaded 467 times

Ji_Li
Posts: 13
Joined: 31 May 2017, 07:16

Re: transverse gradient undulator

Post by Ji_Li » 19 Jun 2017, 15:55

Michael,

Thanks a lot for your patient help.

The plot seems OK now. But I used the generated .ggrad file for BGGEXP in this way:

RWGG: BGGEXP,L=2.3, LFIELD=2.3, filename="ggExp.ggrad",strength =-1,Z_INTERVAL=1,symplectic=1

Is there anything wrong?.There is still one error:

Adding BGGEXP data from file ggExp.ggrad for element RWGG #1
Found 9 Cnm* columns
Problem with value of m for page 1 of file ggExp.ggrad for BGGEXP RWGG #1

Ji

michael_borland
Posts: 1933
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: transverse gradient undulator

Post by michael_borland » 19 Jun 2017, 16:02

ji,

The remaining problem (the error message) is that m=1 was a case that we originally thought shouldn't be allowed, because it normally means a bending magnet and the BGGEXP element is not prepared to perform coordinate transformations needed for bending magnets.

Unfortunately, a fix for this will need a new version of elegant. That's planned in the next week or two already, so please stand by.

--Michael

Ji_Li
Posts: 13
Joined: 31 May 2017, 07:16

Re: transverse gradient undulator

Post by Ji_Li » 19 Jun 2017, 16:43

Michael,

Thanks, I am looking forward to the next release.

Is possible to calculate the ID's contributions to damping partition numbers and synchrotron radition integrals in the next version? Those are quite improtant for our case, a Robinson Wiggler. So far we can calculate those numbers by slicing the wiggler into dipoles based on the trajectory inside the wiggler, and hopefully do tracking with BGGEXP method. It would be nice if we don't have to deal with the linear part and nonlinear part with different modules in Elegant.

Ji

michael_borland
Posts: 1933
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: transverse gradient undulator

Post by michael_borland » 19 Jun 2017, 17:01

Ji,

I'll have to think about how to implement radiation integrals etc. I usually do this based on an analytical model of the element.

I could fairly easily add beam moments computations with radiation from BGGEXP elements, but that doesn't include the damping partition numbers.

--Michael

michael_borland
Posts: 1933
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: transverse gradient undulator

Post by michael_borland » 23 Jun 2017, 16:32

Ji,

Can you post a lattice file that includes the wiggler embedded in the ring? I'm adding code to compute the equilibrium beam properties etc in the presence of a BGGEXP element, and need something with which to test the code. Also, it will be helpful to know the expected answer for damping partition, emittances, damping rates, etc.

Thanks.

--Michael

Ji_Li
Posts: 13
Joined: 31 May 2017, 07:16

Re: transverse gradient undulator

Post by Ji_Li » 27 Jun 2017, 12:15

Michael,

Thanks for your work and help.

Two examples are attached. Robinson Wiggler was represented with Ftable and 10000 dipoles,respectively. In "slicing" folder, you will see the estimated emittace value, damping partition numbers and so on after running elegant. The values in the para.txt file were estimated based on my own code. I think the small difference might because the bending magnets were sliced into many short ones in my code.

Please note that I give a factor of -1 to make sure the field input is right for calculation.

Ji
Attachments
examples.zip
(25.84 MiB) Downloaded 642 times

Post Reply