**Computation Details for the Curious
and Unsuspecting**

Unless you are really getting excited about doing your own calculations or may be refining those presented here, you may wish to skip this section. We are going to wallow in some of the nitty-gritty details needed to solve the equations. It also will assume the reader is familiar with physics and computer programming.

*Drag coefficient calculation-non spinning
case*

The drag coefficient on a non spinning ball was calculated using the
data of Achenbach that is displayed in the section on the Magnus Effect.
To obtain the proper value of the drag coefficient at every time interval,
the curve was fit to an arbitrary function of a type known as a rational
equation. The points to fit were manually transcribed off the published graph.

Rational equations have the general form:

There are many software programs which have regression routines to fit data to specific functions. SigmaPlot (ver 4.0), a scientific graphing program which has regression capabilities, was used to do a least squares minimization to find the constants a-g. The points shown in the Achenbach figure were the data from the experimental plot. The line represents the actual fitted data. [Update-December 28, 2006. There is a singularity in these equations which manifests itself at very high V/U ratios. The change is in a narrow range, which may not affect the calculations substantially. I am working on a fix.]

*drag and lift coefficient-spinning case*

In a similar manner, the
data for the drag and lift coefficients for the spinning paintball were calculated
using a rational equation. Two sets of data were merged for this, the data from
Davies and the high V/U data from Maccoll. This was necessary because paintballs
will achieve V/U values of around 3 near the end of their flight. The Davies
data only goes to 0.56. The fit to the Davies/Maccoll data is shown at the right.
The points are the data taken from Davies and Maccoll figures, and the line
represents the fit. However, there is a complication in the calculation of the
drag coefficient data for a spinning paintball. The data by Davies was generated
at somewhere around 105 ft/s, and the data replotted by Bearman and Harvey is
in terms of V/U (spin velocity/linear velocity). The Reynold's number for Davies
data was ~9 x 10^{5 }and shows a value of 0.42 at zero spin velocity.
Achenbach's data shows a value of 0.50 in this same Reynolds number region.
To get adequate correspondence between spin and non spin data, it was necessary
to scale the Davies drag data according to the Achenbach data. To do this, a
first order correction was applied: The Achenbach data was used to find the
C_{D} for the non spinning case, and this value was substituted in the
"a" value of the rational equation for Davies spinning ball rational fitting
equation. (The first constant "a" represents the zero spin case, because V/U
= 0.) This assumes that the relationship between C_{D} and V/U of Davies
spinning sphere data are the same at all relevant Reynolds numbers. This assumption
has not been proved, but I believe it is valid enough for the calculations here.
This generally brings up a point that C_{L} data would be better plotted
not as rotational velocity/linear velocity (V/U), but rotational velocity/Reynolds
number (V/Re). The constants for all the different rational equations that were
fitted to the data can be obtained from the source program.

Also, I considered that the spin velocity was constant throughout the entire flight. This assumption is not realistic. The air resistance around the ball would likely cause the spin rate to decrease. The question is how fast. Some people on the rec.sport.paintball group think that it will be damped very fast,within a short distance from the gun. Others like me are not so sure. I believe a rough answer to this question is already available somewhere in the fluid dynamics literature. I just have not had time to dig it out. Until I or someone else does, I will assume the the drag effect on spin is small and therefore negligible. Realize that the answer to this could make a real change in my estimations of spin effects.

*equations of motion integration*

The equations of motion were solved using the Euler-Richardson numerical
integration method. The code was based on an example in the book by Gould
and Tobochnik (see references); this was modified for the 3D case here.
I found this method particularly easy for following the programming logic.
A better integration method probably is a Runge-Kutta strategy. This may
someday make its way into the Java version of the program, but required
more work kinetically then I had time for. The time interval was fixed at
0.001 seconds. Most trajectories were on the order of 3- 5 seconds, so
that 3k-5K calculation cycles were needed. On my PII/400 the time for most
simple trajectory calculations was under ten seconds, even in the worst
cases. The original coding for all the results produced here were written
in Excel 97 brand of Visual Basic so that all the calculated values could
be dumped to a spreadsheet. All the graph information displayed here is
the result of some variant of the Visual Basic code.

Once all the coding and debugging were completed, the code was ported to Java code for trajectories used in the trajectory calculator. Details of this can be found in the trajectory calculator page.

The original VBA coding turned out to be straightforward. Converting to the proper units produced the most frustration. The program uses three measuring systems: The trajectory calculations use the mks system, while the calculation of the CL and CD constants used the cgs system. There are two functions to obtain these numbers. Since many of the readers are still mired in the old English system, the metric units were then converted to English units at the end for output. The interested reader will find that there are a lot of comments in the java code to help follow the logic. This is not only for you. If I decide to extend the calculations, I doubt in a couple of months I will remember what I did. Moreover, I do not write code for a living, but do have to use it occasionally.