Elegant users forum

Hi

I have a possible bug in Pelegant 22-1 when using first_is_fiducial. Here is the gdb backtrace, it looks like the index i into columnData goes from 0 to the total number of particles (in this case 1000000), but columnData only contains the number of particles loaded by this processor (333333) so it segfaults. I have built SDDS with MPI = 1 in SDDSlib/Makefile.OAG

James

Hi

Attached ele and lte files for that traceback (the input gun file is ~50MB with 100 pages of 1M particles each produced by the astra2elegant binary from the elegant 22-1 distribution. I was using 3 processors for this test.

Thanks

James

Thanks for reporting the bug. We have found the problem when first_is_fiducial is set to 1, and try to provide a fix for the next release. Our test with less number of particles doesn't crash as the memory read illegally was not used. For a larger test, it will crash. The serial version of elegant should not have such a problem.

Yusong

Hi

It looks like the fiducialization code has been patched in elegant 23.1.0, now I get a large discrepancy between the first and second bunches output from a jitter simulation even when I set the errors applied to both the first and second bunch to zero. Attached are the results when running an identical simulation in elegant 21 and 23.1.0.

James

James,

We are looking into this. Similar tests I did before the release seemed to be ok. Can you send me all of the input files?

--Michael

Did you turn off the ISR? I didn't see it in your template file.
&alter_elements
name=*
type=CSRCSBEND
item=ISR
value=0
&end

If the problem is still there, can you provide the nlsl_0p2nC_schic_m4.lte, so I can reproduce the problem.

Thanks,

Yusong

All files attached. The fiducial bunch takes ~12 minutes with elegant23, second bunch takes ~45 seconds. With elegant21 both bunches take ~45 seconds each. I'm using sample_interval = 10.

File is too large to attach (1M particle astra gun file) so I've put in on our ftp site:

ftp://ftpanon.diamond.ac.uk/jr76/fidallsrc.zip

Thanks

James

James,

I have fixed the problem you found in Pelegant 23. It will correct the result from the CSRDRIFT element for fiducial beam tracking. You can try to use the attached file (put it under elegant directory) to fix the problem before we have next formal release.

For fiducial beam tracking, all the processors will track the whole beam independently to make sure all the processors have the parameters set up correctly for the following steps. So Pelegant won't be faster than the serial elegant in the first step, it could be even slower because of overhead. After the fiducial beam tracking is done, the particles will be distributed to all the slave processors and do real parallel tracking. If you have more steps/passes, you will get better performance using Pelegant. We are thinking about tracking fiducial beam in parallel in future.

Thanks,

Yusong