Implement magnetic field propagator

[whokion]

The first version of FieldPropagator and associated tests:

• Added FieldTrackView
• Added FieldPropagator
• Added state accessors of GeoTrackView to support FieldTrackView
• Added FieldPropagator.test

[sethrj]

I might not be able to resume the review today, so here are a couple of comments. I think we should try to encapsulate all the navstate-related aspects of the FieldState into the GeoTrackView itself, but that's just my first instinct rather than something I've really thought through about what parts (e.g. step and safety) belong where.

[whokion]

@sethrj Regarding to navstate-related interfaces, I am totally open to move things to GeoTrackView, which potentially remove unnecessary public accessors of vgstates which I introduced.

[sethrj]

OK, I think the questions about the persistent state (safety distance) and FieldPropagator will help shape how we can move some of the pieces into the GeoTrackView.

[whokion]

@sethrj I guess that I resolved most of outstanding issues for this MR besides those related to GeoTrackView and utility interfaces/functions using the vecgeom navigator, which we may be addressed in a separate MR. Can review the change
and consider to merge this MR if there are no obvious things to changes at this moment. Thanks.

[sethrj]

@whokion Thanks, sorry I didn't have a chance to merge this or review it in more detail. Can you, me, @pcanal, @amandalund, maybe @tmdelellis interested meet today at 2 pm eastern/3 central to discuss the interface? I'd like to get that in place before resuming the review.

[whokion]

@sethrj Yes, I am available anytime this afternoon.

[whokion]

@sethrj I would like to close this MR (delete the branch) and open a new one as this branch adding new files has been significant changed from the initial version (i.e, removed FieldTrackView and un-needed public (vgstate) accessors of GeoTrackView which were introduced for the defunct FieldTrackView, and changed many interfaces with using GeoTracView instead of FieldTrackView and etc.) - you may take a quick look at the current branch, which is very close to an upcoming new one except a coupe of more clean ups (such as returning pos and dir instead of OdeState which should be agnostic to GeoTrackView or the higher level transport interface or class. One more question is whether FieldPropagator can modify GeoTrackView data (i.e, pos and dir by available stters) directly. In the real work flow, I think it should be the case, but we may also send an intermediate result of the field propagation to the high level transportation manager which can update things accordingly in one central place. As shortly discussed last Wednesday, we agreed to go with the latter (which is reflect in the current implementation), but the first option will also reduce unnecessary data copy. Either is okay for me now, but just want to know your preference. One more note is that the current field propagator updates the final vgstate inside the class anyway as the final direction from the last sub-step before the boundary is used for the final direction for updating the vgstate, which is different from the final (momentum) direction by the stepper. Anyway, please let me know whether I can delete this one and create a new one. Thanks.

[whokion]

@sethrj This MR is now ready to be reviewed. Thanks.

[sethrj]

I'm satisfied. Thanks for the iterations!

[sethrj]

Thanks @whokion!

[whokion]

@sethrj Thanks a lot for all reviews and the merge. The next plan is to add/support 1) a non-uniform magnetic field case, 2) a small angle approximation for detecting the boundary intersection. Of course, I will closely follow up related interfaces to geometry/transport processes as well as further improvement/optimization of existing field codes. If you have a different priority and plan, please let's discuss at our usual meetings.