Fix on atfastring

[lfarv]

Fix the bug reported in #305.

[lfarv]

In fact, there was a bug on each side ! Though not optimised, it should be ok for the moment.

[lfarv]

For the radiation version of the fast ring, the non-linear and diffusion element are swapped compared to the initial version and to the Matlab version. I think I remember this make a difference (on the equilibrium state) in the first tests we did a long time ago. Are you sure they can swapped ? Maybe @simoneliuzzo or @carmignani remember, I may be wrong…

[lfarv]

@swhite2401 : line 61: what kind of error do you want to ignore ? It would be better to be more precise to avoid ignoring unexpected errors.

     try:
         qd_elem = gen_quantdiff_elem(merged_ring)
         fastring.append(qd_elem)
     except:
         pass

[swhite2401]

I think this change is fine, however we generally use fond_orbit_sync for this kind of calculation without radiation. This is why I had suppressed the warning.

[lfarv]

Agreed, but in this case, dct=0 is strictly equivalent to dp=0 : it's the on-momentum orbit. And it's the default behaviour.

[swhite2401]

@swhite2401 : line 61: what kind of error do you want to ignore ? It would be better to be more precise to avoid ignoring unexpected errors.

     try:
         qd_elem = gen_quantdiff_elem(merged_ring)
         fastring.append(qd_elem)
     except:
         pass

I think this was a simple way to manage the case where ring.radiation=True but damping is off -> cavity only

[swhite2401]

For the radiation version of the fast ring, the non-linear and diffusion element are swapped compared to the initial version and to the Matlab version. I think I remember this make a difference (on the equilibrium state) in the first tests we did a long time ago. Are you sure they can swapped ? Maybe @simoneliuzzo or @carmignani remember, I may be wrong…

Why would this be an issue?

[lfarv]

Why would this be an issue?

No idea. I just remember that the equilibrium phase-space when running a large population was different, but again I may be wrong. It could be tested again

[lfarv]

I think this was a simple way to manage the case where ring.radiation=True but damping is off -> cavity only

Ok. Do you know what class of error this raises ? If this is not clear, I'll put except Exception: to remove the warning…

[swhite2401]

I think this was a simple way to manage the case where ring.radiation=True but damping is off -> cavity only

Ok. Do you know what class of error this raises ? If this is not clear, I'll put except Exception: to remove the warning…

I am not quite sure, I think it is the cholesky transform complaining (ValueError?), I can check that later today, but what you propose is fine

[lfarv]

Well this tool is not so stupid: except Exception: is still too broad… Anyway, that's good enough.

[swhite2401]

Well this tool is not so stupid: except Exception: is still too broad… Anyway, that's good enough.

haha ok then I check later today and let you know

[swhite2401]

I confirm this is a ValueError so we can improve the try/except block accordingly

[lfarv]

The except clause is now more strict. OK for merging ?

[swhite2401]

ok for me!