-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Addition of Resonator and Resistive Wall functions as direct passmethods #674
Comments
You are correct interpolating large tables is slower than the analytical calculation... this would nevertheless require significant changes in the architecture (both python and C) that is fully based on generating tables. |
Do you think it makes sense to have both? We keep the python implementation that we have now, which allows for example a resonator to be added to other wakes with the wake table, and then in addition to this we have a direct C implementation which is good for speed and more accurate (no interpolation) but can only be used as a standalone element. |
I would like to keep thinks general, maintenance is much easier this way |
I will think about how to implement this cleanly. |
Quick speed benchmarking with the following script:
BLMode = Phasor: tracking time = 3.66s |
While running tests for #658 , I realised that actually the TRW example is rather slow. One of the reasons for this is likely due to the fact that the function is in python (not directly in C) and the srange has to be specified as an input. When it is like this, on each call to the function you have to first find the appropriate index (binarySearch) and then make the interpolation (getTableWake). For a finely sampled wake or a long wake, this can be a time consuming process.
This is avoided for the BeamLoading module where the longitudinal resonator is directly written in the C (it was done like this to avoid the interpolation around 0 where there is a discontinuity). The Beamloading is therefore fast while the others are slower.
Should we consider adding new PassMethods for each function? This would mean that we make the following additional PassMethods:
LongResonatorPass
TransResonatorPass
TransResWallPass
which may further clutter the atintegrators directory.
The text was updated successfully, but these errors were encountered: