Skip to content
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

Make Field a GeometricObject #149

Open
leon-vv opened this issue Dec 16, 2024 · 0 comments
Open

Make Field a GeometricObject #149

leon-vv opened this issue Dec 16, 2024 · 0 comments
Milestone

Comments

@leon-vv
Copy link
Owner

leon-vv commented Dec 16, 2024

Strategy for supporting Fields as GeometricObject, and tracing through multiple fields

The Field class will keep track of:
Field.origin (a three dimensional point)
Field.unit_vectors (a 3x3 matrix, representing the unit vectors)

Whenever Field.map_points is called, the origin and the three unit vectors are updated (and also the field bounds).

Note that the transformed origin and unit vectors implicitly define two mappings:
local -> global: map a point or vector from the local coordinate system (in which the geometry was defined) to the global coordinate system (in which the fields are being moved freely)
global -> local: the inverse mapping

Whenever a potential or field is calculated by calling one of the methods on the Field class, the input point is mapped to a point in the local coordinate system. The subclasses need to implement new functions potential_at_local_point, etc. which can be called by the Field base class. This way the user can always move around the field within the global coordinate system, and the field will always give the correct answers when supplied by points in the global coordinate system.

The Tracer class needs to be upgraded to understand Field classes with transformed origin and unit vectors. The class needs to transform (global -> local) the starting position and velocity of the particle, and after computing the trace map all the positions and velocities of the particle back (local -> global), such that the illusion is maintained that the fields are completely defined in the global coordinate system.

At a later point in time we will implement a more advanced Tracer (in the pro version) which does not get a single field as input but multiple fields. Note that the strategy of translating just the input position and velocity does not work anymore since different fields will have different transformations. Therefore, every time we compute a field in the Runge-Kutta tracer we need to translate the position and velocity to the local coordinate systems of each of the fields, then translate back the fields to the global coordinate system. To ensure tracing will stay fast, this translation needs to be implemented in C. To prevent duplication of logic, the C code which performs the mappings need to be available to the Python Field class.

@jobdewitte jobdewitte modified the milestones: v1.1, v1.0.0 Dec 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants