Feature Request: Allow configurable access to trajectory_calc parameters

[serhiy-yevtushenko]

Use case:
Simulating shots with high launch angles (close to 90 degrees)

The constanct cMinimumVelocity is set to 50 in trajectory_calc.

However, in case, when one would like to simulate shots with high launch angles, the limitation of cMinimumVelocity to 50 leads to simulation being aborted in the following line in trajectory_calc:

            if velocity < cMinimumVelocity or range_vector.y < cMaximumDrop:
                break

For lofted trajectories this may lead to the situation, that shot is simulated till reaching some high point, and then simulation is aborted, and the descending branch is not being simulated.

Having the ability to set cMinimumVelocity to zero would allow simulating shot to the end.

Possible changes include:

• allowing programmatic configuration of the trajectory calc parameters (with explanation for the influence of values in the documentation)
• changing cMinimumVelocityValue to 0 (This will fix the demonstrated case, but I'm not able to estimate it's influence on other cases)

Example demonstrating issue:

from matplotlib import pyplot as plt
from py_ballisticcalc import (
    PreferredUnits,
    Velocity,
    Angular,
    Temperature,
    Distance,
    Pressure,
    DragModel,
    TableG1,
    Weight,
    Ammo,
    Weapon,
    Shot,
    Calculator,
)

PreferredUnits.velocity = Velocity.MPS
PreferredUnits.adjustment = Angular.Thousandth
PreferredUnits.temperature = Temperature.Celsius
PreferredUnits.distance = Distance.Meter
PreferredUnits.sight_height = Distance.Centimeter
PreferredUnits.drop = Distance.Meter
PreferredUnits.angular = Angular.Degree
PreferredUnits.pressure = Pressure.hPa

max_distance = 2_000
drag_model = DragModel(
    bc=0.759,
    drag_table=TableG1,
    diameter=Distance.Millimeter(23),
    weight=Weight.Gram(188.5),
    length=Distance.Millimeter(108.2),
)
ammo = Ammo(drag_model, Velocity.MPS(930))
weapon = Weapon()

zero = Shot(weapon=weapon, ammo=ammo, relative_angle=Angular.Degree(85.5))
calc = Calculator()
shot = calc.fire(zero, Distance.Meter(max_distance), extra_data=True)
shot.plot()
plt.show()

zero = Shot(weapon=weapon, ammo=ammo, relative_angle=Angular.Degree(86.5))
calc = Calculator()
shot = calc.fire(zero, Distance.Meter(max_distance), extra_data=True)
shot.plot()
plt.show()

In the first case, the whole trajectory till hitting ground is getting simulated, in the second case the simulation is being stopped in the middle. Such unpredictable behaviour makes it hard to use ballistic calculator inside optimization/root finding algorithm (like in scipy or similar)

[o-murphy]

@serhiy-yevtushenko
If you are using the pure python version (py_ballisticcalc.exts package not installed) u're not limited by types annotations of the library, so as temporary sollution you can directly change cMinimumVelocity

from py_ballisticcalc import trajectory_calc
trajectory_calc.cMinimumVelocity = 0

@dbookstaber
It would be nice if you took a look at this and assessed the possibility/necessity of such an improvement.

[o-murphy]

@serhiy-yevtushenko I work on more flexible concept of a TrajCalculator class to allow advanced users to define their's own logic of calculations for special cases, but the result will not be very soon, and besides it will add overhead costs

[dbookstaber]

The problem is that the current TrajectoryCalc does a simple Euler integration and sets its step size based on the velocity. This will get bogged down as velocity_vector.x gets very small, and of course fails if it actually reaches 0. Ref this line:

# Time step is set to advance bullet calc_step distance along x axis
delta_time = self.calc_step / velocity_vector.x

If you don't care about simulation speed and you don't simulate a scenario in which velocity_vector.x ever becomes 0 then it's OK to set trajectory_calc.cMinimumVelocity = 0.

The correct approach is to use higher-order integration, like what I have implemented in the RK4 branch. However currently those implementations still require velocity_vector.x != 0, so (amusingly) they won't handle a purely vertical trajectory. I think we can change the _calcMethod == CalcMethod.RK_dt version to not reference velocity when setting its delta_time. Then we could simulate purely vertical trajectories.

• One good unit test would be to check terminal velocity on a dropped object (i.e., muzzle_velocity=0).
• We should also add the unit tests suggested here.

[o-murphy]

@serhiy-yevtushenko @dbookstaber
Starting from version 2.0.7 you have the ability to override global settings individually for each instance of the calculator

For other calculation methods, such as the one provided in the RK4 branch, I can add the ability for the Calculator interface to set up a custom solver class. Then, you can inherit from TrajectoryCalc and implement custom calculation logic.

Next, we will review what else needs to be done to adapt the code to support custom solvers and how to save it easily maintainable. Such an expansion of capabilities could become the next major release, so it will require discussion and suggestions

[o-murphy]

I think the issue topic request is satisfied in #104, you have the ability to configure the Calculator now.
Other calculation methods should be more widely considered, so I'm moving this issue to discussions

[GRKSEO]

This is an interesting issue! The problem with the simulation being aborted when using high launch angles seems to stem from the cMinimumVelocity threshold. By allowing it to be set to zero, it could help simulate lofted trajectories to the end, as you've suggested. This change could be very beneficial for those of us working with ballistic calculators in optimization algorithms, where we need more predictable and consistent results. For anyone facing similar challenges, the full explanation and code in this article may be helpful: Python Calculator Guide.