Closed dbookstaber closed 6 months ago
One critical break found between the two with the .50BMG 30° look angle Example:
Where zero()
only sets these initial values:
mach = shot_info.atmo.mach >> Velocity.FPS
density_factor = shot_info.atmo.density_factor()
trajectory()
updates them each iteration via:
density_factor, mach = atmo.get_density_factor_and_mach_for_altitude(alt0 + range_vector.y)
After 2000' trajectory the zero()
velocity is 20m/s higher than the trajectory()
calculation! (Which seems backwards, so I'm digging into the calculation and use of density_factor
and mach
.)
Actually the big break in previous comment's example was that zero()
doesn't apply powder temperature correction, if that has been selected.
The reduced drag at higher altitudes is a smaller effect, but still visible: If we hold the density_factor
and mach
number static (at their initial values) in trajectory()
then for a high-angle shot we do get velocity and drop values that are increasingly lower downrange, as expected.
Presently
TrajectoryCalc._zero_angle()
and._trajectory()
use a similar but not equivalent implementation. In the end, the zero_angle doesn't care about windage, and it ignores other details that are handled in the "full" trajectory calculation:Winds
Otherwise, the only difference is that
trajectory()
is checking each iteration for various flags and recordingTrajectoryData
rows, whereaszero_angle
is checking forrange_vector.y
hitting the zero.Doing the full trajectory calculations while finding searching for zero_angle shouldn't (TODO: verify?) be much more compute time than what it does at present. Benefit:
zero_angle
will matchtrajectory
under all conditions, whereas now there will be breaks due to winds and/or cant_angle.Therefore: The two methods should share the same initialization and step logic.