sddsconvert conversion bug?

[Björklund]

Hi,

This is my third forum entry in a short while, but I hope I run out of problems soon

I am trying to use a particle input file from my colleague's PIC simulations with Pelegant, so I need to have it in binary. I have previously run the same input file on elegant, using the .txt (ascii) and not the .sdds version, without problems. I wrote my own conversion script going from the output file of his simulation code to an elegant-compliant format, formatting it to look like a watchpoint output file.

This has worked flawlessly before, albeit a bit slowly since I used ascii input, but when I convert to .sdds, the values in the columns are changed. Particularly the time values are changed, see attached pictures, but the spatial coordinates are also changed by a small amount.

I have attached 3 files (parts of them anyway, since they are much too large), where one of them is my own conversion from the PIC file to an elegant file, i.e. my input file, and the two others are the first watchpoint files when running with the input file as .txt and .sdds, respectively. I have run with 1/10th of the particles in the input file, hence the difference in length, and in my own conversion script I didn't include a function for changing the particle identifier (which might or might not be the cause of this problem). I didn't include the input file in .sdds, since the whole file is very large and I wouldn't know where to cut it. The first watchpoint is at the beginning of the line, so the output from this point should give the unchanged particle input (to my mind at least).

There are also two figure files, showing plots of the first watchpoint in my beamline using either the .sdds or the .txt file as input. This is how I discovered the problem in the first place, as the .sdds is clearly distorted in time, though seemingly not so much in energy.

Best regards
Jonas

[michael_borland]

Jonas,

If I understand this, the Input.txt file is the file that you feed into elegant. The problem I see with this file is that the coordinates appear to take on three discrete values. If I take the file and do

Code: Select all

sddsconvert Input.txt Input.sdds

then

Code: Select all

sddsdiff Input.txt Input.sdds

I get "Input.txt and Input.sdds are identical," so I can't see a reason for the differences.

If you can send me a sample run that exhibits the problem, that will help.

--Michael

[Björklund]

Hi Michael,

Yes, the input files are indeed what I feed into elegant, the .txt (ascii) file being what I used when I ran just elegant and the .sdds being what I now run when having switched to Pelegant.

As you see from the figures, the coordinates don't appear to be the same even at the first watchpoint where they really should be the same. There is a difference in the coordinates between the input file and what I get out from the first watchpoint, which really should be identical, I think. So maybe the error isn't in sddsconvert, but somewhere else, maybe even my own code, although I just copy-paste values from the files.

I'm not sure what you mean by sample run though, but If you just examine the first few rows of the two watchpoint files, you will see a difference in the coordinates. Those watchpoint files are from the first watchpoint and have been run with .txt and .sdds as input, respectively, and each correspond to what's been plotted in the figures, where the whole data set is displayed. I see the same effect from the .sdds (i.e. the distortion in long. phase space and some small shifts in trans. phase space) in both elegant and Pelegant.

Please let me know what other files you would need, e.g. the sample run you requested. The full files are too large to transfer as it is now, but I could do a quick run with a smaller fraction of the particles and send those files if it would help.

//Jonas

[michael_borland]

Jonas,

I tried a few runs with a lattice consisting of a single WATCH element. I used Input.txt and Input.sdds (converted from Input.txt using sddsconvert) and used both elegant and Pelegant. The results appear identical.

So I'm unable to duplicate any of the symptoms you are seeing. I may not be doing exactly what you are doing, so it is hard to guess where the problem might be. To do a sample run, I'd need all the input beam files, the lattice file, and the elegant command file. The input beam files can be truncated, as long as the problem still shows up when you use the truncated files.

--Michael

[Björklund]

Hi,

All right, I'll try to truncate the input file in a way that would allow you to see the problem. I'll post again later.

Isn't it a problem in its own right that the values change at all from the input file to the first watchpoint, though? Or do you also not see that issue?

//Jonas

[Björklund]

Hi Michael,

I've now gone throgh my files and cleaned them up a bit so they are easier to read, you'll find them attached. Included are my .ele, .lte, .bat and input files. I just removed the particle duplication part (to account for different weights in the PIC code) from my conversion from the PIC-file to truncate the input file, I have checked it and I still get the same error. However, now I only get it when running Pelegant; I can run the .sdds file in elegant and get the same result as for the ascii (.txt) file, which I am assuing to be mostly correct. Thus, I don't think the problem lies in my matlab script.

If I look at the coordinates for some particle in the input file and at watchpoint w-0, there are still some small differences between the two, even for the elegant runs that look good when plotted. I think this is really weird too.

Thanks for taking the time to look at this
Best regards
Jonas

[michael_borland]

Jonas,

Thanks for the files, it was very helpful.

Looking at the &sdds_beam command, I see that you have sample_fraction=0.1. Unfortunately, sampling doesn't work the same in elegant and Pelegant, so this will introduce an unavoidable difference between the serial and parallel versions. Hence, if you want to compare serial and parallel versions, set sample_fraction=1.

You may still see some differences even after doing this. These can be eliminated by setting center_transversely = 0 and center_arrival_time = 0 in &sdds_beam. Setting these to 1, as you have, means that elegant modifies the input coordinates to center them. This will definitely cause differences between the first watch point and the input file. It may also cause small differences between serial and parallel results, because the sums used to find the centroids necessarily get done in different order.

By the way, there is an SDDS extension for MATLAB, which might eliminate the need to convert files to ASCII.

--Michael

[Björklund]

Michael,

Thanks a lot for taking the time to look at it! It's much appreciated.

Not centering in time solved the issue. The bunch is so extraordinarily short that even small shifts made a big difference. Of course this mostly "washes out" during transport, but still. Transversely, I realized that these small shifts are actually beneficial, since I just duplicate particles from the PIC code according to their respective weights, but I don't redistribute them within the sizes of those macroparticles. Incidentally, this is more or less what happens when I set center_transversely to 1. It is very good to know the source of this behavior nonetheless.

I'll have a look at this SDDS extension, it would speed up the total simulation + post-processing time a bit not having to convert to ascii.

Best regards
Jonas

[Björklund]

Michael,

One last question, a bit off topic but hopefully easy to answer now that you have all my files...

I'm using exact_normalized_emittance = 1 in global_settings because of my very non-monoenergetic and divergent beam (which causes a strong emittance growth, see below), and I want to track this number along the beamline using the sigma outputs. This worked in elegant, but in Pelegant, it returns 0.00...e-0 in the normalized emittance columns if I have the above value set to 1, but returns a value when set to 0. Any specific reason for this?

About the emittance growth, which I saw was discussed in another thread when looking for a solution to this problem; it is pretty much only seen in beams that have a large divergence and large energy spread (and/or large size) and is an effect of different rotational velocities in transverse phase space for the different beamlets in energy. This means that you'll see chromatic effects even in drifts, which I thought was quite counter-intuitive at first. I found the following paper on the topic a while ago: M. Migliorati et al., Intrinsic normalized emittance growth in laser-driven electron accelerators, Phys. Rev. ST Accel. Beams 16, 011302 (2013), http://journals.aps.org/prab/abstract/1 ... .16.011302.

Best regards
Jonas

[michael_borland]

Jonas,

It appears that I forgot to implement the exact emittance computation for the parallel version. To add insult to injury, I don't think the implementation for the serial version is correct. We'll get this fixed for the next release.

Thanks again for your questions.

--Michael