Sim:Ballistics

Simulating Ballistics

My simulation requires ballistics to be fairly realistic and, as important, systematic, as the design of simulated gunsights must match the ballistics closely. You can find a sample range table creating using my process here.

What is a Range Table?

A range table is a series of rows sorted by range in 100 yard or 100 metre intervals detailing the performance of a given gun firing a given shell with a given powder charge under given conditions. The columns of each row contain different characteristics of a firing of the shell to the given range, such as the angle of elevation required to reach that range, and the time of flight of the shell. These parameters are all functions of the range for the gun/shell/powder system being described as it is exercised through ranges up to its maximum range.

In different eras, different nations used different formats for range tables. Apart from variations in choice of unit to be be employed (e.g.: yards or metres), as time passed more columns would be added in the name of completeness or to suit some new need.

I created virtual range tables to permit me to judge the accuracy of how I simulated a shell's passage through the air, as I am interested in simulation games and the players of such games get downright uneasy if you cannot demonstrate the exact nature of how your pretend weapons work, and they get argumentative if you cannot illustrate the data you selected as its basis in reality. Consequently, I decided to center on range tables as a means of illustrating in quantitative terms how my simulation performs so that intelligent challenges can be made to its accuracy and suggestions for improvement can be rationally considered. In the best case, having a number of virtual range tables which differ only slightly from tables created for the real weapon system might serve as a basis for judging the accuracy of those simulated weapon systems for which no real world range table has been located for comparison. Ideally, when sufficient confidence in the simulation logic has been established, questions of the accuracy of any simulated system model can be confined to the real world data chosen as inputs in creating its virtual analog.

Finding Input Data

It may sound like cheating, but the best source for input data is a real world range table for the weapon system being modeled. A historical range table is a primary source document that is hard to impeach even if it may lack some desirable information. Having a complete table on hand also provides the modeler with a nice template for creating his program's output, and a complete master document against which his results can be compared.

Here are the portions of the historical range table I used as the basis for my simulation of the weapon system shown in my example table. You'll note that although the table has 200 entries (100 yards through 20,000 yards in 100 yard increments), I only employ the most extreme range/elevation pair. In all, these are the data I required:

1. diameter of shell (drag area depends on this)
2. weight of shell (obviously important in a physics-based sim)
3. radius of curvature of the shell's head
4. total length of the shell (obtained from another source)
5. muzzle velocity (I am modeling the CPC Mark Ia shell)
6. the most extreme range/elevation pair available to me

All other data in the range table can be inferred by using physical simulation. The simulation must be sufficiently "true" for this to work, but the good news is that the historical range table itself can serve as a nice check of the end result — how closely do the simulated data entries agree with those in the range table?

Simulation Methodolgy

Equipped with only data above, I am able to systematically infer all other values in the table with a high degree of accuracy. The experimental process used to calculate this occurs in 3 phases.

Phase 1: Characterize the Drag Coefficient as a function of Mach

A given projectile's drag coefficient changes as it passes through the air as a function of the speed of sound. I rely on a version of R. L. McCoy's "McDrag" program of 1974 to calculate the drag/Mach relationship for the shell, and then run a series of simulated test firings to determine a scaling (or "fudge") factor so the weapon system's simulated performance exactly matches a real-world datum firing at extreme elevation.

The McDrag code requires the shell's mass, diameter, radius of curvature of its head, and overall length to create an approximate function of drag coefficient at different Machs. While I respect the authority of the ballistics expert who created this complex set of equations, I need to take the raw McDrag curve and hammer it until it works exactly for my simulation. I chose the coarse expedient of scaling the curve.

The process of determining the proper scaling factor to use is iterative, with test firings being done in simulation. I start with a "fudge factor" of 1.0 which assumes that the McDrag function is perfect and fire a simulated shell at the muzzle velocity and elevation given in my historical data. If the shell goes beyond the historical target range, I increase the scaling factor used in that trial (to make the shell "dragger") and test again. Using a binary search much like firing ranging shots at a target, I determine a drag coefficient which makes the weapon system closely match the historical test shot. In this case, I insisted that the best shot in Phase 1 firing series fall within 0.1 meters of the range given. If memory serves me, Phase 1 required just 6 firings to achieve this epsilon, and the scaling factor found to work was 0.913. Once this phase is complete, we literally know everything needed to replicate the gun's performance if we are willing to disregard drift and 50% errors (which I am not covering in this document). However, if we want to be able to actually print out the range table, we need to take our now properly simulated gun out to the range and collect more "real virtual" test firing data.

Phase 2: Replicate, in Simulation, the Proving Ground Tests

Historically, range table data were the result of a process much like this phase: the guns were taken to a well-surveyed proving ground and fired 8-20 times at different elevations and the time of flight and point of impact for each shot was noted. A series of corrections were then applied to offset any difference between actual firing conditions and the nominal standard for the service, and mathematical methods were then used to create data for angles of impact and culminating point (apogee). In our virtual equivalent, we are blessed with perfect weather conditions and rely less on fancy mathematics and more on "actual" test firings. Since it is unlikely that we'll ever fire one of these guns again and the only "weapon" we'll ever create a sighting mechanism for will be a virtual one incorporating the same code we're using, this is ideal.

In the Phase 2 test firing series, the program fires the virtual gun at a number of different elevations to demonstrate the entire envelope I'd like to characterize in a range table. It starts with an elevation of 1/8 of a degree with the shell just above ground level and fires the simulated shot. Another shot is taken at 1/4 degree, and 1/2 degree, and one degree. Then at 1 degree intervals until we reach (say) 10 degrees, and a series at 2 degree intervals upwards from there and maybe even 3 degree intervals if I want to support very high elevation mountings. One could clearly get a nice range table indeed if one fired thousands of shots, but the truth is that only around 10 or 20 are needed to get a pretty accurate range table because you are going to perform spline-based interpolation between the data you measure from this relatively small number of firings.

For each test shot, we measure and record the range, elevation, time of flight, angle of fall, culmination point (apogee), and impact velocity for the shell -- all the fundamental data we'd like to feature in the columns of the real range table that was our primary source. Then, we "spline" the values from these columns taken at this series of elevations. As background, a spline is a series of N-1 third-order polynomials that can be used to approximate a curve defined by N sampling points -- the nice quality of this representation is that the curve is continuous and passes through all the sample points and flows smoothly. In this way, even though the relationships are subtle and difficult to characterize symbolically, splining them provides us a flexible description of their nuance that is continuous through 2 derivatives.

I compute the following splines using the data above:

• range to elevation (column 2)
• range to time of flight (column 3)
• range to culminating height (column 4)
• range to culminating distance (column 5)
• range to angle of descent (column 6)
• range to remaining velocity (column 7)

Column 8 in the table shown (Danger space in yards for a 30 foot target) is merely 10/tan(column 6) . Curiously, I note that the historical table has an incorrect value for this -- it should be 25 yards at the angle of descent cited.

Coming up with a value for Column 9 requires me to perform a third phase of test firings.

Phase 3: Same as Phase 2, but with a slightly reduced M.V.

The last phase requires the elevation series used in Phase 2 to be fired again, this time with the muzzle velocity reduced by an increment (in the case of this table, 10 feet per second). The loss in range reached is splined and values read off this are the grist for column 9. At this point, the columns of the range table are fully represented by smooth splines relating their value to range. All that remains in this application is to print out a range table in a format similar to the historical document.

Printing an HTML Range Table

The range table printing portion of the application simply has a boiler plate form for an HTML web page. It reads the name of the weapon, the dimensions of the shell, etc, from the range table data structure, and prints the column headers. Range is iterated between 100 and 20,000 yards in 100 yard increments, and the range table's spline functions are queried to supply the necessary data for each column, converting each value into the desired units. Presto -- a nice range table which should very nearly approximate the real weapon system (see discussion of errors below) and very accurately match the performance of the simulated shells (if one wanted to use the same physical modeling logic in a simulation game, for instance).

Other Features of the Ballistic Simulation

While this is already quite a web page, the simulation does still more. It can fairly approximate ballistic drift (the better the data on hand, the better will be the simulation, though it is not as strictly physics-based as are the above behaviors. It is also capable of fudging in "50% Errors" for the weapon. These too are not elegantly simulated, but the end result is the same, statistically. Drift and these varied sources of imprecision are very difficult to characterize mathematically and so this is why I instead chose a data-fed method for introducing these effects. I am fairly confident that the physical simulation of projectiles in this package is faithful enough to the important details of performance that few interesting questions would be answered incorrectly by regarding its results as authoritative (subject only to the quality of input data provided, of course).

Lastly, I consider it a fundamental feature of this to be that data supplied to simulate a weapon system not just become numbers thrown over a wall and cauterized from any provenance or citation as to their origin. Consequently, all the data objects and expressions that create them provide a means to "footnote" the data and indicate where it was obtained. This will allow a means to check the work, and to understand if and why a better reference might have been found.

Missing Features in the Ballistic Simulation

• Wind, when used, is considered to be uniform at all altitudes.
• The shell's drag coefficient to the wind does not consider yaw.
• Coriolis effect is not modeled.
• Shells never yaw or become unstable in flight.
• Effects of humidity are ignored.
• Barometric pressure is treated simply.
• Atmospheric modeling could use a real expert's help.

Discussion

Methodology

As to methodology, I'll offer just one thought: how closely do splines track these dissimilar relationships? The litmus test for this question would be to conduct virtual test firings and see how they compare to the corresponding lines in the simulated table. I've not done such a test yet. One remedy, of course, would be to conduct vastly more test firings and create a range table where each row recorded a specific virtual test firing. This would take advantage of the fact that it costs very little indeed to fire a virtual gun!

Errors

You will see that my range table does not perfectly match the historical one. Some of these errors seem tolerably small, and others start to threaten to be too large. What is up with that?

Some of the errors are in the original tables consulted. The tables themselves were based on a series of just 10-15 test shots being taken on a range. The intermediate rows on the table were entirely a product of mathematical interpolation techniques which might, in some cases, have been approximations less reliable than my physical simulation technique (at least, when it is sufficiently advanced).

Additional experimental errors applicable to the real world gun system but not my virtual one are that the gun might not have been fired under conditions exactly matching the standard Royal Navy atmospheric conditions, and hence the very first step would be an imperfect but well-chosen correction step which amounted to a series of rules of thumb and tables being consulted. The real weapons engineers presumably had no real means at all to guess at the culmination height and distance save a sound mathematical formula (this is not such a big deal, however, as the culmination point is nearly trivia). Lastly, it bears mention that materiel was sometimes wanting in the Royal Navy, particularly early in the 20th century. A good example of this was that shell weights varied significantly from the norm, and I don't know whether all early test firings had the individual shells weighed. Even if they were, the rules of thumb to neutralize their deviations from the norm may have introduced errors. 50% error zones, as measured in breadth and length, were probably based on a statistically insignificant number of sample shots intended to gather this information.

For other errors, let's focus on the entry for 20,000 yards, as this is where the differences are most profound given the extent of simulation shells have undergone by the time they reach that range. In the following, I have converted all angular measures into pure degrees.

	Elevation degrees	Time of Flight seconds	Culminating Distance yards	Culminating Height feet	Angle of Descent degrees	Remaining Velocity feet per sec	Variation of Range yards
Real Table	14.753	34.72	11090	4903	22.00	1365	108
My Table	14.752	34.62	11084	4865	22.08	1342	125
Difference	-0.001	-0.10	-6	-38	+0.08	-23	+17
	0.00%	0.29%	0.05%	.78%	0.37%	1.69%	15.74%

Don't be TOO impressed by the accuracy in elevation at 20,000 yards -- recall that this range is the one I coerced the system to match in Phase 1 of the calibration process. A fairer metric for this might be to look midway into the table, where my elevation was .035 degrees less than the historic table's (0.62%). I am at a loss to explain the Variation of Range discrepancy -- it is shockingly large and I did not used to get this error in older versions of the code. All remaining errors I think I am fairly comfortable with, but improvement is apt to be found in creating a fuller atmospheric model. I hope that I find knowledgeable persons to help me in that quest, as I am not eager to learn about humidity and such, but if someone can fortify my code in this area without altering the design of the logic too grossly, I'd be keen to hear from them.

I look forward to creating a more accurate system and then pushing on to see what else this can be applied toward. More range tables for different weapons are a sure thing, and I invite you to share any such data you may have. I personally have extensive RN tables for 1910 through 1918 and can pretty much do them all.

See Also

• Range Table

Tone 13:35, 8 February 2012 (EST)