Ballistic Program Inconsistencies

[Kyle_freemason]

Over the past 5 years I have began to really become involved in long range shooting/hunting. I have over the years used various ballistic software and find that each has its pros and cons as you would suspect.

What I cannot understand is why these programs give varying trajectory information -- some being very close to where the bullet actually struck with the given conditions, some being in the general area of being right and some that I have tried are up to 13 inches off. My question is, how can there be so many ballistic programs and each gives much different drop information?

It seems to me that just like with math, especially with physics that if you input the right information you get the right information out. 2+2 is always 4 and yet it seems that despite that fact ballistic programs still vary drastically in their output information. We all know that of the varying equations used and theories (for example between the work of Mccoy and Pejsa etc) that only one will be correct and that is proven when the bullet strikes the paper. It would seem only logical to me that researchers would have built upon eachothers work and came up with equations that accurately depict where the bullet will strike, afteral, it is only math right?

So why are there so many programs out there giving wrong information and using wrong data whhen we know there is the right data out there?

Help clear up my confusion... please!

Kyle

 

[BryanLitz]

Kyle,
There are many reasons why programs can give slightly different answers, but few reasons why they may give drastically different answers.

Here's a list of some things that come to mind:
Solution method. Certain simplifications of the math are made in some solution methods to get to an answer. The Siacci and Pejsa solutions are examples of solution methods that use 'short-cuts' to get to an answer. These short cuts are usually not very costly in terms of accuracy. The Pejsa solution doesn't interpret BC the way other programs do. Solutions that use numerical integration (point mass solutions) will compromise the least accuracy.

Atmosphere. There are two definitions of the 'standard' atmosphere in common use: Army Standard Metro (ASM) and ICAO (something like: International Civil Aviation Administration). Some programs use one, some the other. BC's are also defined by one or the other. One possible error is to use a BC that's defined based on ASM in a program that uses ICAO or vise versa. This will introduce an effective error of 1.7% in the BC (or air density) that you're using.

Of course there is user error to consider. If the inputs are misleading or unclear, one could accidentally enter inconsistent information.

My advice is to check whatever program you use against the JBM online ballistics program. JBM uses a point mass solver, and is extremely accurate. You can tell how accurate your program is by seeing how well it compares to JBM.

-Bryan

 

[Kyle_freemason]

Hi Brian,

Thank you for the reply, I do see where you are coming from and the differences it would cause. I was just very surprised to see how some programs varied up to 13 inches in elevation for the same bullet and information. I do like JBM and wish that he would make it in pc format so that I could use it offline. In pda version would also be a huge plus.

I will for now stick to using JBM as I have found it to be about the most accurate.


Thanks again!

Kyle

 

[BryanLitz]

Kyle,
Out of curiosity, can you tell me what programs you were getting 13" of difference with? That seems like a lot and these kinds of things interest me.
Thanks,
-Bryan

 

[Kyle_freemason]

Bryan,

I will compile a list of programs I used when I get home from work this evening. I can even send you the programs as some are no longer available. Do you know of any program that is comparable to the results of JBM in accuracy that I could use on my pc when I am not connected to the internet or on my pda? I am really looking for an accurate program for my pda using palm os.

Thanks again!

Kyle

 

[BryanLitz]

Kyle,
The point mass ballistics program that comes with my book (Book) matches JBM within round off error (fraction of an inch) at ranges beyond 1000 yards. They're essentially the same solution written by different individuals which use the same atmosphere model.

There are several iPhone apps that can use G7 BC's. To my knowledge, the only one for windows based mobile devices is Loadbase 3. I'll be working on developing another program for mobile devices (Palm, blackberry, windows, etc) over the winter.

-Bryan

 

[Kyle_freemason]

Bryan,

I am very interested to read your book. I will have to save up some pennies -- times are still hard here in the Midwest. Your program sounds very appealing, while it for now will only work on a pc, I could atleast use it on the laptop while out punching paper -- something I cannot do with JBM.

Some of the programs I found that were way off are:

Ballistix - Based on Pejsa's work

BalCal

Excelbal - Jackson Rifle excel sheet based on Pejsa

Point Blank

Al Bal

Of the programs I have found to match very closely to JBM one stands out it is created by Derek Yates and is GNU Exterior Ballistics.

Hopefully soon, I will be able to order your new book, learn something new and use the ballistic calculator you have created.

Thank you for all of your replies Bryan!

Kyle

 

[BryanLitz]

Kyle,
Of the programs you listed, I'm only familiar with AlBal. I downloaded it some time ago and have compared it to my program and JBM and found it to be in close agreement.

Here's the case I run:

caliber: .308
Bullet 155 grain
G7 BC = .230
MV = 3000 fps
sight height = 1.5"
zero range = 100 yards
air temp = 59F
air press = 29.92 inHg
humidity = 0
(these are ICAO standard sea level conditions)

Those conditions produce the following outputs in 3 programs:
Bullet path at 1000 yards:
JBM: -317.6"
Point Mass Ballistics (my program): -317.74"
AlBal: -317.75"

I consider all 3 of these to be practically equal. They're all using the same atmosphere, and interpreting BC the same way.

It's not surprising to me that programs based on the Pejsa method would produce different answers, as that method doesn't interpret BC in a conventional way (thus the requirement for the additional variable; the '****** coefficient' or 'drag coefficient' as it's called in different applications).

If you have easy access to those other programs on your list, I'd be curious to see how their predictions compared to the above for a similar input set.

-Bryan

 

[Kyle_freemason]

Bryan,

I will run the various programs using the data you give and type out the results based upon your bullet and your G7 bc. Then you will be able to compare results

Here are the results I got after writing this post:

Ballistix - 1000 yards -1211.2

GNU - 1000 yards -316.07

Excelbal - 1000 yards - Based on Pejsa (could not caculate past 500 yards)

Lee - 1000 yards -652.50

BalCal - 1000 yards -299.3

Results are in inches. It seems GNU was the only program to garner the same results as your program, JBM and AlBAL.

 

[BryanLitz]

Kyle,
Yea, GNU is good.
BalCal is only off by ~17", this could be an atmosphere definition incompatibility.
However, Ballistix and Lee are way out in left field. I suspect one of two problems:

1) Either they're interpreting the G7 BC as a G1. Do the programs let you tell them you're giving it G7? If not, it will not know better and treat it as a G1, hence the extreme drop.

2) The Pejsa method requires 'splicing' different solution methods between speed regimes. There are different equations required for supersonic, transonic, and subsonic speed. IF the solution doesn't properly splice the solution (let's assume it's using the supersonic solution thru-ought) it will be way off at long range because it's using the wrong equations. This is why the one program responsibly cuts off at 500 yards; to avoid invalid calculations at low speed.

I suspect it's the first of the above two guesses. The velocity isn't low enough to really be into the transonic set of equations.

Thanks for the details,
-Bryan

 

[Kyle_freemason]

Hi Bryan,

Lee does not allow for a change in drag, so I do believe it rated your B.C as a g1. However, despite this fact, no matter if you use a G1 B.C they are still WAY off. This is what I was never able to understand...Maybe they just use the wrong equations to begin with.

Kyle

 

[jeffjackson]

I got interested in this a few years ago while writing some of my own software.

I have written software on my own using most of the available methods to compare and contrast; Numerical Analysis (like McCoy), Step-wise, Siacchi and Pejsa. This may get kind of geeky, but I think a lot of folks contribute differences to methods more than they should. Personally I found differences in how many different packages implemented and used drag curves. For instance, I originally had trouble getting the Siacchi I had implemented to match the McCoy (JBM) results. As I dug deeper (I have a background in math, computer science and physics) I realized that most of the published drag curve data that gets used with Siacchi and step-wise methods didn't match that used by most numerical analysis methods. To be more specific, if you look at McCoy's implementation he uses the CD vs. Mach table to express drag curve, Siacchi requires it be expressed in a certain set of curve formulas. When I went back and derived my piece wise curves to use with Siacchi from BRL published CD vs. Mach I found them to be different and started getting very close results with Siacchi well past 2000 yards. I also found that more packages gave more similar results for G1 than the other drag curves. That may be changing with more people looking at them than they did a few years ago.

To adress the original posters question. First all, I found several packages to be plain wrong, but among those that are "correct" a lot of the differences you see that are small can be attributed to many things. One guy uses more precision for constants (such as gravity), one package may vary environment (like air density or gravity) over the trajectory where another guy keeps them constant. I think how many people convert pressure to station pressure may vary or be in accurate. Even how folks pick CD vs. Mach values can vary for a specific velocity, for example, one guy uses a simple linear interpolation and another guys uses something a little more sophisticated. I played around with several of these things and they make very little differences, a lot less than other variables such as BC or environment can be measured, but they do result in many different packages giving slightly different results.

If you really want to see packages give different results start changing away from standard environmental conditions, I found packages to start varying wildly, especially with temperature.

 

[BryanLitz]

Jeff,

Thank you for sharing your expertise!

I've also found small differences in the Siacci solutions compared to numerical integration. I suspected that it had to do with a definition of Cd vs Mach, but never tracked it down. I just applied a correction factor (about 1 or 2 percent) to the air density that resulted in very good matches at long range.

Another compromise in the Siacci approach (at least the implementation given in McCoy) is that the integrals use velocity as the independent variable. The problem is that temperature changes the speed of sound, which changes the CD vs velocity relationship (not the CD vs Mach relationship); so when you get away from standard temperature, the tables are off. It's a small amount, and doesn't tend to matter much, but is one of those things that will, as you said, cause solutions to diverge as you get away from standard atmosphere.

The software you've written, is it available commercially?

What's are your thoughts on the Pejsa solution?

It's good to know there are other 'geeks' out there who are pay attention to this stuff!

-Bryan

 

[jeffjackson]

Bryan,

Good point on the velocity vs. mach for temp. I had thought about that at one point but didn't do any experiements to measure the affect/outcome, etc. You've piqued my interest again though . The other place I noticed was that when people convert from sea level pressure to station pressure I think some use the station temperature in the conversion and some don't. I arrived at this conclusion more empirically than by examining implementations since I can't look at source for most of the packages out there. I kind of struggled with finding a "good" formula for converting sea level pressure to station pressure.

I thought the Pejsa solution is novel and i think he deserved a lot of credit for coming up with a solution to a problem he was trying to solve at the time; i.e. a set of formulas for a system with limited compute/storage capabilities. I think a lot of folks over the years who approached external ballistics and realized how non-trival it is (solving interdependent differential equations) had the same thought/wish; i.e. surely there is something simplier. Implementation wise I found it very similiar to Siacci. The formulas are definately a lot simplier though. Trying to find the right values for your bullet seems to be problematic. I thought it would be interesting to measure the error of a default set of values that match different standard drag curves to put a number to how closely his formulas and 4 zone approach could get to representing the standard drag curves, but never got back to it. I always thought that might be the limiting factor to his approach but didn't spend enough time with it to say one way or another or if more zones would improve it.

As a computer scientist i found it interesting to contrast and compare the different methods on their compute, space, etc. requirements. While methods like Pejsa and Siacchi are less compute intensize on the trajectory calc. In order to find out things like PBR etc. its additional expense since you end up having to refine your way to solutions to find things that are almost free in the other methods, since you can capture them along the way.

Yes I do have some of my own software. Let me put up a new version and then I'll send you a link. Would love to have any feedback. I have come close to releasing it several times, but always seem to come up with one more thing to do or the day job just takes too much time or consumes too much of my thoughts

Jeff