Page 1 of 1

bug in astra2elegant

Posted: 28 Jul 2009, 09:33
by michael_borland
There is a bug in the astra2elegant script that will show up in particular for very long bunches. The bug results from not accounting for the fact that the output file from ASTRA is a snapshot of the beam at a fixed time rather than a record of particle coordinates crossing a fixed z plane. Attached is a corrected version of the program. (I also fixed a less significant problem wherein v was used instead of vz to compute the time coordinate from z.)

Thanks to Philippe Piot for identifying this problem.

The program astra2sdds.c from the ASTRA web site also has this error. In addition, it assumed v=c when computing t from z. I've included a corrected version of that program.

In the next release of elegant, the script astra2elegant will be replaced by a compiled program that is much faster. It creates SDDS binary files (unlike astra2sdds), so the files are much faster to manipulate and read. (The ASCII SDDS files created by astra2sdds.c take a very long time to read compared to binary files.)

--Michael

Re: bug in astra2elegant

Posted: 10 Sep 2009, 07:14
by jrowland
Hi

I'd like to point out that astra2sdds.c doesn't take into account the arrival time of the reference particle which makes it unsuitable for jitter studies. We had some fun with that.

Thanks

James

Re: bug in astra2elegant

Posted: 10 Sep 2009, 08:56
by michael_borland
James,

Good point. I actually eliminated this feature in the C-code version of astra2elegant, but will add it back.

Meanwhile, in case anyone needs it, here's an updated version of astra2sdds.c that includes the offset.

--Michael

Re: bug in astra2elegant

Posted: 10 Sep 2009, 09:51
by jrowland
Thanks for the fix, now is there any important difference between the two programs? I was planning to standardize on astra2elegant.

Re: bug in astra2elegant

Posted: 10 Sep 2009, 09:57
by michael_borland
James,

The only important difference is that astra2elegant will in the future be much faster, as it will be compiled (like astra2sdds) and also write SDDS binary.

--Michael

Re: bug in astra2elegant

Posted: 30 Oct 2013, 00:52
by alexei_sav
I am using astra2elegant V.2 Sept 2009 (I do not have astra2sdds). I noticed that the emittance calculated by ELEGANT for the SDDS imported is ~2 times (~1/0.51) higher than that I have had originally in ASTRA though Courant-Snyder Beta looks the same. In analyzing the SDDS file (with sdds2plaindata), I found that the reason is that the standard deviation of the transverse momentum has correspondingly increased after the conversion (though maximum spread of it remains ~correct) and the C-S Beta has actually decreased by factor of two. Also the stdev of time coordinate has increased by factor of ~1.66 and max time spread by factor of ~2.65. All other parameters are seemed being converted correctly (coordinates and the big momentum). I am curious is there still kind of bug or I am using an obsolete version... Thank you for any advice how to fix it, also appreciate the astra2sdds link.

Re: bug in astra2elegant

Posted: 30 Oct 2013, 08:35
by michael_borland
Alexei,

I suspect there may be some units confusion in various emittance computations. astra2elegant doesn't apply any numerical factors other than c. E.g., it computes x' = px/pz, t=z/(beta*c),... There's no place for factors such as your found to come in that I can see.

If I remember correctly, ASTRA outputs the transverse momentum in eV/c units, so if emittance is computed directly from these coordinates you might get differences related to 0.511.

astra2sdds is (was?) from the ASTRA web site, so I can't do more than supply the C code (as above).

--Michael