Add magnetic field drivers/integrators

[whokion]

Implement magnetic filed integration with a realistic geometry and a non-uniform magnetic field, and test different integrators on GPU.

• Runge-Kutta stepper Runge-Kutta Stepper #173
• Adaptive step solver Magnetic Field Driver #214
• Integrate with geometry/navigator (safety distances, high-level Propagator, etc.) Implement magnetic field propagator #221
• Nonuniform magnetic field Support user-defined magnetic fields #250

Possible Quantized State System (QSS) implementation?

• A Stand–Alone Quantized State System Solver for Continuous System Simulation
• Efficient Discrete-Event Based Particle Tracking Simulation for High Energy Physics

Possibly implement simpler steppers (e.g. helix) for uniform magnetic fields

[whokion]

@sethrj I scratched out classes for the magnetic field integration (FieldPropagator -> ChordFinder -> Driver -> Stepper -> Equation -> Field) with minimal functionalities (without a boundary crossing for now, which can be extended later when navigation is fully working). One question before moving forward for actual implementation is regarding to how to pass required input for the field integration (i.e., position, direction, kinetic energy and mass (for the momentum three vector), proposed step length, charge) which is combined but parts of information from ParticleTrackView and GeoTrackView. In fact, the data format that I would like to use is {y(position,momentum), dydx{rhs of equation}, step_length, charge} where y and dydx is an array of dim-6 real_type, which are common input/(output) to most functions of those classes. Is it worth while to introduce something like FieldTrackView which only contains a set of minimal input for the field integration or just use the ParticleTrackView and GeoTrackView directly?

[sethrj]

Excellent! I really like the FieldTrackView idea. What about a FieldTrackView that is be a temporary class whose constructor takes a ParticleTrackView and GeoTrackView? The constructor could do the necessary transformations (e.g. {energy, direction} -> momentum) into whatever data format is easiest for the propagation classes, or you could provide accessors that calculate the data on-the-fly. (Either way, I'd use accessors like we do with the other view classes to allow the implementation to change later.)

Does that sound like a good approach?

[whokion]

Sounds great! I will introduce FieldTrackView and will ask your review later. Thanks.