You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: