Challenge: detailed trajectory points output

[yramachers]

Geant4 minimum position unit is a G4Step with two points: from, to. Step length is calculated according to processes, i.e. in a thin medium (gas, vacuum) such step lengths are huge and only bounded by geometry boundaries. Helical motion in a field would not be represented if points on the helix are required even though the G4PropagatorInField object calculates the helix completely using the combination of a chosen 'stepper' object, i.e. the ODE solver algorithm run by the G4ChordFinder, and an equation of motion object.

Geant4 has the notion of a G4SmoothTrajectory, which retrieves from the G4Step a vector of Auxiliary Points (put there via the propagator in field object - long chain of command via the G4Transportation object). Explicit switching on of this unusual feature is required. It appears that an instance of a concrete class inheriting from G4VCurvedTrajectoryFilter set in the propagator object is required. That filter object stores the auxiliary points in a std::vector according to user design, from all to some number of points as G4ThreeVector positions.

Needs testing and caution on potentially huge memory use. Our helix will cycle many, many times before any process takes places or a boundary is hit. Maybe consider summarising the helix in memory with a fit and store only fit parameter instead of the complete set of points?