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:
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:
Point Mass Ballistics (my program): -317.74"
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 'retard 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.
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.
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.
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.
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!
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