Confusion with the notion of drop_adj/windage_adj and possible error in windage_adj

[gambon2010]

Hi! I've come across something I find a bit weird in the results of the calculation, especially with the results regarding wind calculations.

lets take an example with the wind coming from the left: for wind = Wind(velocity=Velocity.MPS(10), direction_from=Angular.Degree(270))

distance     time    drop_adj windage_adj
0    0.0 m  0.000 s    0.00 mil    0.00 mil
1  300.1 m  0.421 s   -1.30 mil   -1.66 mil
2  600.1 m  0.972 s   -5.06 mil   -3.80 mil
3  900.1 m  1.705 s  -10.89 mil   -6.49 mil

If we assume an x axis where + is up and - is down, and were to trace this in a 3d environment drop_adj would give us the predicted drop of the bullet (so renaming this variable drop_prediction or drop_pred would make more sense)
on the other hand for windage_adj, if we assume a z axis where + is right and - is left, here the name is correct as we need to shoot left to hit the target if the wind is coming from the left. So we get an adjustment instead of a prediction.

Now if you remove wind and just look at the spin drift we get this:

  distance     time    drop_adj windage_adj
0    0.0 m  0.000 s    0.00 mil    0.00 mil
1  300.1 m  0.421 s   -1.30 mil    0.05 mil
2  600.1 m  0.972 s   -5.06 mil    0.12 mil
3  900.1 m  1.705 s  -10.89 mil    0.23 mil

Here lets only look at the windage_adj and assume the same considerations as above, in your standard barrel spin drift moves the bullet to the right. So looking at the results, here we get a windage_prediction (move to the right as the value is positive) and not a windage_adj! (the adjustment should be negative, or to the left, to hit the target)

I am by no means a ballistics expert, but to me it seems something is wrong.
I would either change the concept of drop_adj to drop_prediction (which would make more sense with a negative drop value). Change the name of windage_adj to windage_prediction, keep the spin drift value as a positive number, and add a *-1 somewhere in the windage calculation to make it a prediction instead of an adjustment.

Or keep the names the way they are, but change the drop_adj so a positive value comes out, keep windage as is and subtract the spin drift instead of adding it.

Personally, drop_prediction and windage_prediction makes more sense to me, then calculate your adjustment by taking the value *-1

[gambon2010]

@o-murphy

[o-murphy]

Hey, dude!

firstly the notion "adjustment" was declared in original golang based sources, so to avoid misunderstanding about that notion on library versions update and saving the readability we use it as is.

About positive or negative values of adjustment. It's often depends on preferred by the user, scope manufacturer or the ballistic solver developer, so if u want u can inherit from TrajectoryData instance and add/overload method to return the data with sign u want.

We already had a discussions with @dbookstaber about twist direction and was accepted current version is valid. The latest version of trajectory calculation function was written by him. So u can ask him about additional description.

If u want to contribute to the project u can create a fork of master branch, add your changes, update tests as needed and create an MR. After review we'll merge it to the latest commit

[gambon2010]

Hi! thank you for the reply! Dbookstaber found were the issue was coming from, 0 degree wind comes from behind the shooter, not the front (which i assumed). So the wind results being backwards makes complete sense.
I'm still delving into the projects code, but if I come up with any interesting improvements I'll be sure to create a branch =)

[o-murphy]

Hi! thank you for the reply! Dbookstaber found were the issue was coming from, 0 degree wind comes from behind the shooter, not the front (which i assumed). So the wind results being backwards makes complete sense.

I'm still delving into the projects code, but if I come up with any interesting improvements I'll be sure to create a branch =)

This way to get the wind direction is coming from common usage this property by other ballistic solver programs. Most of them uses clock face arrow based direction. 12 o’clock is 180 degree, means that wind blows from this direction. This way assumes using wind direction relative to shooter’s position and how he can imagine it in real life

[dbookstaber]

Yeah, there are two potential confusions here:

1. The use of the suffix "_adj" for the fields that are expressing the trajectory components in angular units. Maybe it would be better to use the suffix "_angle." Of course a shooter would dial the scope in the opposite direction to "adjust" for the change in trajectory.

2. The wind direction angles can be confusing. You have to check the code to see that left/right is the opposite of what you thought:

class Wind(PreferredUnits.Mixin):
    """
    Wind direction and velocity by down-range distance.
    direction_from = 0 is blowing from behind shooter. 
    direction_from = 90 degrees is blowing from shooter's left towards right.
    """

[gambon2010]

Thank you for the reply! Now I understand why all the wind calculation results were backwards ^^