[Feature💡] n_transverse_cells is hardcoded to 1 — should it be a user-configurable parameter?

[saraadastan]

Hi,
During Wakefield simulations of scraper geometries for the Elettra 2.0 synchrotron, I found that n_transverse_cells is effectively hardcoded to 1 in two places:

wakeSolver.py: self.n_transverse_cells = 1 (default, never exposed to the user)
routines.py: xx, yy = slice(self.ixt-1, self.ixt+2), slice(self.iyt-1, self.iyt+2) (hardcoded ±1, ignores the attribute above)

When I changed both to use n=3 (7×7 transverse grid), the transverse wake potentials WPx(s) and WPy(s) improved significantly compared to CST Wakefield Solver. With the default 3×3 grid, the gradient W is undersampled and the results are noisy.
The appropriate value of n depends on the geometry, for example, for scrapers and collimators a larger grid is needed, while for symmetric cavities n=1 may be sufficient.
My question: would it make sense to expose n_transverse_cells as a proper user-configurable parameter, so the user can set it based on their geometry before running the simulation?

I would be happy to contribute a PR if this is of interest.

Thanks,
Sara

[elenafuengar]

Hello Sara,

This is great news! :)

Thank you so much for reporting your findings. Indeed, we are working now with some people of the Muon Collider on validating the transverse wake potential integration, because as you reported in your previous issue, the results can get noisy very quickly.

It would be great to have your implementation in a pull request, we can definitely expose it in the WakeSolver class instance. Maybe it is also worth to look at higher order integration methods to compute the gradient. So far, only a second-order central differences scheme is implemented.

Thanks again for supporting and using Wakis 🫶

[elenafuengar]

Following this morning's discussion, here is a short reference document with different numerical differentiation schemes: https://www.dam.brown.edu/people/alcyew/handouts/numdiff.pdf

[saraadastan]

Hi Elena,

I wanted to share an update on my investigation into the n_transverse_cells issue.
While testing whether setting n_transverse_cells=1 with a polynomial fit would reproduce the original finite difference (FD) results, I noticed the two methods were not giving the same output — which made me suspect something else was wrong beyond the gradient scheme itself.
After careful debugging, I traced the discrepancy to a copy-paste typo in calc_trans_WP in wakeSolver.py:

`WRONG:
np.savetxt(self.folder + "WPy.txt", np.c_[self.s, self.WPx], ...)

CORRECT:
np.savetxt(self.folder + "WPy.txt", np.c_[self.s, self.WPy], ...)`

WPx was being saved into WPy.txt, which, for a beam with a y-offset, produced a near-zero WPy — a clearly wrong result. I confirmed the fix is already in the current GitHub version. With the corrected code, I tested n=1, n=3, and n=7 with polynomial fitting, and all of them give the same result as the standard FD method with the corrected saving, so increasing n_transverse_cells does not bring additional benefit for this geometry.
I am currently working on a PR to add kick factor and loss factor calculation functions in the style of CST, which I think would be a useful addition for the community.
Thanks again for the support and for this great open source project.

Regards,
Sara