Error in SpaceChargeCalc2p5D::bunchAnalysis and Grid1D::getIndAndWZ while tracking and pyorbit stop

[chiragpatidar]

While investigating effects of space charge in presence of placements and field errors in accumulator ring lattice for long term tracking, I am encountering error message after few turns and the PyORBIT stops. The error messages are either

1. SpaceChargeCalc2p5D::bunchAnalysis(bunch,...) The bunch min and max sizes are wrong! Cannot calculate space charge! x min =1.79769e+308 max=-1.79769e+308 y min =1.79769e+308 max=-1.79769e+308 z min =1.79769e+308 max=-1.79769e+308 Stop.

   or

2. Grid1D::getIndAndWZ Wrong z value. It should not happen. Stop.

The initial beam distribution used for tracking is KV in transverse and uniform in longitudinal plane . The errors in lattice elements are Gaussian with sigma values that are typical observed values in practice and no correction scheme is applied. No aperture restriction are applied in lattice. SpaceChargeCalc2p5D (no boundary) and LspaceChargeCalc are used for space charge calculations. I could not understand whether the error message is due to some flaw in PyORBIT or something unusual is happening with beam distribution while tracking. I am attaching file I have used for tracking. Lattice_and_other_files.zip

[shishlo]

Dear chiragpatidar,

I think that the errors and messages that you see are happening because your bunch is empty, and there is nothing to track. Could you perform control of bunch size during the tracking, please?

Best regards, Andrei Shishlo

[chiragpatidar]

Dear Sir,

Thanks for your precious time and suggestion. While looking further into this error, I figured out that this error is due to some particle's co-ordinates in the bunch become nan. Due to nan co-ordinates in the bunch, space charge algorithm generate the message while finding maximum and minimum of bunch. Before a particle's co-ordinates become nan, its phase space co-ordinates grow very high (many thousand times ) as compare to rest of the bunch. I thought that space charge is causing this growth for particles having specific initial conditions. To check this hypothesis, I put one more particle with almost similar initial co-ordinates in the bunch to see whether both particles co-ordinates show growth and nan co-ordinates but this time, some other particle show co-ordinate growth and occurrence of nan. Further, I tracked particles without space charge and observed that in this case also particle's co-ordinates become nan after almost similar number of turns (1st particle co-ordinate become nan at 27 turns with all type of errors and no space charge) as with space charge case (1st particle co-ordinate become nan at 24 turns with all types of errors and space charge) but this time py-orbit keep tracking the particles without showing any error message. The number of particles with nan co-ordinates grow turn by turn and within few hundred turns half of the bunch particle's co-ordinates become nan. Then I did the same simulation after reducing sigma of the errors to half, but this time also problem of particle's co-ordinates becoming nan appears but after few more number of turns (150 turns in this case when 1st time nan appear).

  I could not understand why particle co-ordinates become nan in presence of errors and why py-orbit beep tracking those particles without any error?

with regards, Chirag Patidar

[shishlo]

Dear Chirag Patidar,

I could not understand why particle co-ordinates become nan in presence of errors and why py-orbit beep tracking those particles without any error?

Well, I agree that having NaN is bad, but to check any mathematical operations with coordinates will take recourses from CPU. It is user responsibility to look after macro-particles, and if coordinates are non-physical remove these particles from bunch using apertures.

As for your situation, I suggest to simplify your code and take a look at particles when no space charge and no errors in the lattice. Also, you can take a look at particles coordinates during the tracking using your custom child nodes at the start and exit of your lattice elements, or use action container and action definition like in https://github.com/PyORBIT-Collaboration/examples/blob/master/SNS_Linac/pyorbit_linac_model/pyorbit_sns_linac_mebt_hebt2.py from line 271 to 335.

Best regards, Andrei Shishlo

[chiragpatidar]

Dear Sir, Thanks for your time and suggestion.

I tracked a single particle in bare lattice (no error and no space charge) of accumulator ring for 1000 turns. There is no skew quadrupole in the lattice. The result of the tracking was compared with madx code. In py-orbit, there is huge growth/shrink in transverse phase space area of particle while madx tracking shows no such behavior.

For 0-600 turns, horizontal phase space area grows with spiral trajectory of particle while vertical phase space remains nearly same. After 600 turns, the horizontal phase space continues to grow and vertical phase space shrink. The longitudinal phase space matches fairly well with madx results.

I think there should be no growth and shrink of transverse phase space as there is no skew quadrupole. Is there any bug in teapot tracking? Or I had something wrong?

I am sharing files that I used for tracking and the output files along with a doc file showing phase spaces for 0-100 turns, 0-400 turns, 0-600 turns and 0-1000 turns.

Looking forward to your reply!

Hybrid_6p88_6p88_bare_lattice.zip

[shishlo]

Dear Chirag Patidar,

Sorry for my delay with answer. I took a look at your scripts and lattices. I think that I cannot help you, because you are using different lattice files for PyORBIT and MadX. I cannot confirm that they are the same or not. In addition it is a very complex example for analysis and comparison. I suggest to simplify your example, or if it is impossible try to track one particle and print out all 6D coordinates of this particle during the tracking at entrance and exit of all lattice elements for MADX and PyORBIT. Eventually you will find where the discrepancy starts.

Best regards, Andrei Shishlo