Retile mesh functionality

[MarkusSQ]

Description

Added functionality which allows the user to change the mesh extents of space charge elements during runtime, without the need of removing/recreating SC elements and rebuilding tracker. Grid count remains unchanged. Compared to re-using replace_spacecharge_with_PIC(), it removes the need to rebuild the line each time.

Right now the user themselves will need to implement in their own script when to retile the mesh, and to what new extents etc. For example, in the case of using space charge elements originally created with replace_spacecharge_with_PIC(), the user themselves will need to make sure the relative mesh extents for the different elements in the line are kept.

This functionality has been implemented for SpaceCharge3D objects with either FFTSolver3D or FFTSolver2p5D as solver. A new testfile (test_change_pic_mesh.py) has been added to test the functionality.

Usage:

On a SpaceCharge3D object, call either the function set_xy_mesh() or set_xyz_mesh() with desired new ranges, and optionally if stored rho, phi and dphi_* should be set to zero after the retile. Doing this will call either retile_xy() or retile_xyz() with the given arguments. The retile functions will change necessary values for the fieldmap, and thereafter call refresh_geometry() on the fieldmap's solver. refresh_geometry(), which takes the x/y/z-grids as input, will in turn rebuild the Greens function for the new cell sizes.

If zero_fields=True for either retile- or set_*_mesh functions are used, this avoids using fields calculated for an old mesh when e.g. update_on_track=False during tracking. When e.g. update_on_track=True, this option does not matter as fields are overwritten anyways.

It is possible to directly call the retile functions and/or refresh_geometry() given one has access to a fieldmap and/or solver, if one does not wish to modify higher levels (not recommended outside of testing).

Checklist

Mandatory:

• I have added tests to cover my changes
• All the tests are passing, including my new ones
• I described my changes in this PR description

Optional:

• The code I wrote follows good style practices (see PEP 8 and PEP 20).
• I have updated the docs in relation to my changes, if applicable
• I have tested also GPU contexts