Fix bug in at.c

[lfarv]

elempass was crashing when called several times with a python integrator. This is fixed

Few other fixes related to at.c

[swhite2401]

You are using python passmethods??

Very nice! Much simpler in fact! I have tested it using the example pyDriftPass.py, everything looks fine.

There is one thing that was pointed out to me though, the examples pyDrfitPass.py and PyIdentityPass.py are returning r_in in at/integrators when r_in is modified in-place so the return statement is useless.
I think that is correct, if you agree could we correct these in this PR?

Then I have a question: I personally never use elementpass but rather atpass([element]) is there any advantage to it?

[lfarv]

I agree that the return value of python integrators is ignored. So we can return None. Returning the updated r_in may be interesting if you want to call the integrator directly, as in Matlab (but which is not possible in python for C integrators). So should we remove this ?

Concerning the use of these functions:

1. as it was discussed some time ago, I consider the atpass and elempass C functions as private and favour the use of their "public" python interfaces lattice_pass and element_pass which are safer. I still intend to rename them with an underscore (with a stub tor backward compatibility).
2. element_pass avoids a significant overhead in lattice_pass and directly calls the integrator. So it is more efficient (no idea of the difference), while giving the same result.

By the way, it is while trying to modify the test functions to use the lattice_pass and element_pass that I discovered the bug. Concerning the use of python integrators, I used one for prototyping the "ChangeReferencePass" for tapering with dipoles (still pending), and for that purpose it is very convenient.

[lfarv]

Few other fixes related to at.c:

• another memory leak,
• the openMP status provided by the C function isopenmp is publicly available in at.DConstant.openmp