Interpolate jx_beam and jy_beam to level 1

[AlexanderSinn]

Interpolate jx_beam and jy_beam to level 1 at the start of the refined patch because they don’t get shifted from the previous slice.

Old:

New:

Diff:

• Small enough (< few 100s of lines), otherwise it should probably be split into smaller PRs
• Tested (describe the tests in the PR description)
• Runs on GPU (basic: the code compiles and run well with the new module)
• Contains an automated test (checksum and/or comparison with theory)
• Documented: all elements (classes and their members, functions, namespaces, etc.) are documented
• Constified (All that can be const is const)
• Code is clean (no unwanted comments, )
• Style and code conventions are respected at the bottom of https://github.com/Hi-PACE/hipace
• Proper label and GitHub project, if applicable

[MaxThevenet]

Great, thanks for this PR! See just 1 comment below. Another possibility would be to actually deposit the beam transverse current on the first slice of the fine grid rather than interpolating it from level 0. Could you elaborate on why you chose to do the interpolation? Just faster and simpler to implement? (This is just for the information, I don't suggest we do the deposition.)

[MaxThevenet]

A interp_order stencil was already applied from beam particles to the grid. this is an additional smoothing step that is unnecessary, in particular because we are interpolating to a fine grid to resolve finer structures. A lower interpolation order here should reduce the difference with jx_beam obtained by depositing directly to the fine grid.

Suggested change

	constexpr int interp_order = 2;
	constexpr int interp_order = 1;

[AlexanderSinn]

Currently all interpolation to level one is done with order two. Should the other functions be changed as well or just this one.

[MaxThevenet]

Probably all of them, but we should review this case by case (might sometimes depend on whether it's a source or a field). But you're right, it's not only about this one. Could you open a separate PR setting all others to e.g. 1 (or have a variable controlling them, if that's quick, but we'll probably scan it just in the next few days/weeks before merging the PR and set it to the best value)? Let me know if that works for you, and if so we can merge this PR as is for consistency.

[AlexanderSinn]

Yes, it is easier to change and test everything in one go after merging this PR with order two.

[MaxThevenet]

Let me take it back: we don't need to scan it. I believe that hard-coding it to 1 everywhere is what makes most sense. Then we could just compare old (2) vs. new (1) and see if it's a significant change. But I see no reason how 0 (interpolating from wrong position) or 3 (huge smoothing, as seen from level 1) could ever make sense. So no need to expose it as a variable (unless it's easier in the code).

[MaxThevenet]

ok

[AlexanderSinn]

Let me take it back: we don't need to scan it. I believe that hard-coding it to 1 everywhere is what makes most sense. Then we could just compare old (2) vs. new (1) and see if it's a significant change. But I see no reason how 0 (interpolating from wrong position) or 3 (huge smoothing, as seen from level 1) could ever make sense. So no need to expose it as a variable (unless it's easier in the code).

I agree

[AlexanderSinn]

We could deposit the beam for WhichSlice::This but for WhichSlice::Previous1 the beam slice has already been pushed to the next timestep. The deposition could be done one slice in advance but that is significantly more complicated.

[MaxThevenet]

ok