Find the way to provide more efficient methods of calculation

[o-murphy]

[dbookstaber]

This is implemented in pull request #50

[dbookstaber]

I implemented constant time-step calculation here: https://github.com/dbookstaber/py_ballistics/blob/time-step/py_ballisticcalc/trajectory_calc.py

However it looks like it will always take more iterations than the current method to achieve any particular level of precision, so I do not recommend pursuing this.

[o-murphy]

but in addition to the number of iterations, it is necessary to take into account the time for performing the calculation, it may turn out that due to a decrease in the number of calculations, the number of iterations can be increased without losing performance

we have to make a profiling and performance comparing
u can use timeit built-in module to got time some function are executing

[dbookstaber]

By "iterations" I meant the number of passes through the #region Trajectory Loop to calculate any particular trajectory. (This is without regard to the zero-finding logic.)

I think the current method of setting the time step based on the velocity is optimal. Any other approach will create excess precision at some points and lower precision at others.

[dbookstaber]

To improve efficiency, JBM recommends switching from this simple integration approach to something like RK4, which is what he uses.

[dbookstaber]

I implemented RK4 integration in this branch. It is more robust than the Euler implementation we are running, meaning that as step_size increases errors grow more slowly. However on the example I studied it's not like orders of magnitude better.

This provides a foundation for some desirable improvements, including:

1. Adaptive step_size
2. I included two different RK4 implementations, one using time and the other using range.x as the independent variable. The latter (CalcMethod.RK_dx) version could particularly benefit TrajectoryCalc.zero_angle since, as long as zero_distance % step_size == 0 then it will end exactly at the distance of interest.

[o-murphy]

Right now I don't have much time to study alternative calculation methods, so I'm completely relying on you. In any case, if we're worried about breaking something, we can always implement it as an experimental feature and enable it via the library's global settings. Like we do with gunpowder sensitivity, we can enable an alternative calculation algorithm. Use inheritance, it allows to implement new feature without massive base code changes and lost of backwards compatibility and also allows extend functionality without changing major release version

Create new module, inherit from existing backend.TrajectoryCalculator

# my_new_solver.py
from py_ballisticcalc.backend import TrajectoryCalculator

class MyNewSolver(TrajectoryCalculator):

    def trajectory(*args, **kwargs):
        # reimplement methods you need
        ...

Add global flags to trajectory_calc.py

# existing flags
_globalUsePowderSensitivity = False
def set_global_use_powder_sensitivity(value: bool) -> None:
    # pylint: disable=global-statement
    global _globalUsePowderSensitivity
    if not isinstance(value, bool):
        raise TypeError(f"set_global_use_powder_sensitivity {value=} is not a boolean")
    _globalUsePowderSensitivity = value
    
# new flag
_globalUseNewSolver = False
def set_global_use_new_solver(value: bool) -> None:
    global _globalUseNewSolver
    _globalUseNewSolver = value

Add conditional import of your new solver to interface.Calculator

from py_ballisticcalc.backend import TrajectoryCalc, get_global_use_new_solver

# Calculator class
def barrel_elevation_for_target(self, shot: Shot, target_distance: Union[float, Distance]) -> Angular:
    if get_global_use_new_solver():
        from my_new_solver import MyNewSolver
        calc = MyNewSolver()
    else:
       calc = TrajectoryCalc()

[serhiy-yevtushenko]

Hi, David (@dbookstaber). I have a question for you as expert in ballistics - could you comment on possibility of using methods like described in these and similar articles - https://iopscience.iop.org/article/10.1088/0143-0807/37/3/035001, or http://www.jaac-online.com/article/doi/10.11948/20210277 for speeding up the computations? (Search in the internet gives as well a number of other articles). Are they applicable for precise simulations used in ballistics calculator case or only for gaining insights in general behaviour of the system?

[o-murphy]

@serhiy-yevtushenko

In theory, we are considering the possibility of adding alternative calculation methods, currently the plan is to implement RK. This is something that can be implemented without a significant change in the library architecture without violating backward API compatibility.

As project owner and maintainer I think that after reworking the library architecture, there probably will be a clear opportunity to expand the functionality with methods such as the Adomian decomposition method.
However, it is worth understanding that some calculation methods will significantly reduce performance, with a slight improvement in accuracy. They may be interesting from a scientific point of view, but not so necessary for the ordinary user, whom the project is aimed at.

In addition, the library is developed with minimalism and lightness in mind, while maintaining cross-platform support and the smallest number of mandatory dependencies. Therefore, such innovations will be better implemented as optionally installed plugins.

The next stable version is planned to be v2.1.0. If you change the architecture, please increase the API version to v3

[serhiy-yevtushenko]

Hi, Dmytro. Thank you for the clarification. I believe efficiency could be considered from several viewpoints:

• precision of the computation
• speed of the computation

In my opinion, the benefit of analytical methods lays in speed of computation (compare calculations for drag-free case using formulas from Wikipedia with numerical integration like Euler or Runge-Kutta method).

Runge-Kutta method is optimizing the precision of the computations.

As I am not very experienced in ballistics, it is really interesting for me to hear David's opinion about the usage of analytical methods and their limitations. I'm able to see a lot of articles published in this area, but do not know in general their limitations and areas of applicability. Just for understanding - in some articles on analytical methods it is mentioned that computations could be easily done using a simple calculator (not a ballistic one). So, they are offering at least from a speed perspective a good potential for improvement. At the same time, I have not seen yet articles, that discuss using analytical methods for the prediction trajectories of specific projectiles with specified ballistic coefficient and G-function. Hopefully, this clarifies my question.

[dbookstaber]

@serhiy-yevtushenko, The sorts of analytic approximations discussed in those papers are at best of academic interest, and not considered useful for applied high-velocity ballistics where the drag coefficient as a function of velocity is not only variable but also must be empirically measured. Never mind accounting for variable atmospheric conditions over the trajectory, as we do here!

Applied ballistics passed the point of any speed/precision trade-off half a century ago. Runge-Kutta calculation of trajectories was "fast enough" on early 1980s-era electronics to produce solutions that exceed the precision of the inputs in fractions of a second.

(By comparison, the Euler implementation here is computationally wasteful, but on modern electronics we set step sizes that are orders of magnitude smaller than necessary for precise solutions and we don't bother fine-tuning for speed – and often don't even bother compiling the code!)

TL;DR: Basic numeric integration on these problems is so fast and precise that it's not worth making other approximations or looking for analytic shortcuts.

[serhiy-yevtushenko]

Hi, David. Thank you for the clarification. My experience of running simulation of shots with Euler using py-ballisticcalc was about 40 minutes for 900 shots - so, I would not call it blasing fast (using pure python version). I wonder what kind of performance are you getting with Runge-Kutta method