Implement Strang splitting with space charge

[cemitch99]

This PR modifies the main tracking loop with collective effects to use a second-order Strang splitting.

• increases the accuracy of the space charge calculation by moving from first-order to second-order with respect to the slice step size, currently set by nslice
• ensures that integration in s is time-symmetric, which is needed for reversible back-tracking

Close #846

• simple implementation for the case that nslice is an even integer
• implement and test in the envelope tracking loop
• implement and test in the particle tracking loop
• modify implementation for the case of general nslice
• add benchmark test(s)

A follow-up PR will address Issue #794

[cemitch99]

Here the targets were tuned to analytically-determined values, instead of being set to coincide with a low-resolution run.

[cemitch99]

The original tolerance was too tight.

[cemitch99]

The attached result illustrates the improvement in numerical convergence obtained when running the expanding beam test with envelope tracking (input_expanding_envelope.in).

ImpactX_StrangSplitting.pdf

[ax3l]

Is the reference particle pushed twice now? o.0

Happens again in line 176 below

[cemitch99]

Clarified in person:

• also includes envelope push
• note the difference in weights (half step for push, full step for SC & CSR, another half step for push)

[cemitch99]

We have to make sure that thin elements, which only go through this loop body once, are still only kicked once though.

[ax3l]

A small comment: this PR attempted a map/2 + collective kick + map/2 strang split, because intuitively this keeps the more costly collective kick centered and avoids doing +1 kick per element on its slices.

But, this only holds for Thick-derived, constant-field, non-s-dependent elements as a performance optimization. For thick elements that have s-dependent fields (RFCavity, SoftQuad, SoftSol), for potentially-thick but not easily splittable elements (LinearMap/SpinMap/Programmable) and for all Thin elements, a Kick/2 + map + kick/2 is the self-consistent fallback to use.

Under that viewpoint, I personally would recommend to do optimizations for number of collective kicks done later on: it complicates the code for a subset of the elements, and alternatives to optimize, like merging the half-kick at the last nslice with the next half-kick of the next element could be explored too (both optimizations are a bit messy in book-keeping).

Even with kick/2 + map + kick/2: in practice, because of the lower nslice needed now it might not even always pay off to carve out that one extra collective kick per element... (to be measured). Of course, for low numbers of nslice the cost is big, a regime we can now enter more with strang splitting...

[cemitch99]

Hm; I don't understand your last comment. The idea, as it is implemented in IMPACT-Z, is to use map/2 + collective kick + map/2 for all thick elements. If there is an s-dependence in the field, then the calculation of map is applied by numerical integration via splitting into substeps, whose number is set by the mapsteps parameter.