is this a bug or what? I think i entered everything correctly.

EDIT: i found you cannot have zero for the apogee, but what happens if you are shooting from like 1m away? do u put it as 0.0001?

aww there is graph, and it doesn't show up on mine

and you can't enter an apogee of 0, it has to be above.

y is that exactly? is it because ur coded formulas do not work with some components being zero?

The reason the apogee can't be zero is because the projectile is bound to travel some type of distance upward.

Boiling; looks good, you are getting pretty good at these embedded calculations.

Now, along the lines of asking a program to do something that it was not designed to do...

If you set the "Muzzle-impact spacing" to a large number like 100 meters. Then set the muzzle velocity to a very small number (like 0.1 m/s) and use a Cd of 1 ...

It says the object hits the ground at ~0.1 m/s.

I don't think that's right

Basically, I was trying to model a projectile dropped from a particular height.

----------------

The model assumes the gun is pointing straight up, so you might want to note that on the page somewhere.

Be nice if launch angle and range were also input/output.

----------------

I suspect the reason why the apogee (and some of the other variables) can't be zero has little to do with the math. Boiling is using a cell containg zero (or null, or empty) to decide which things are inputs and which things need to be calculated.
<pre> //Determine which algorithm to use
if (InCd > "0" && InVel > "0") { CdVel() }</pre>

nice... i like it

Ok, people asked for the ability to use the programs for other than strait-up launching.

I simply take the sine of the angle you enter and multiply it by the velocity: this calculates the vertical component of your velocity.
The vertical component of your velocity is then used in the calculations, completely ignoring the horizontal speed.

I think I can do this. Johanna, you wanna comment on this?
*******************

Yeah, the entered values in the "optional" section have to be above 0... which, as jimmy noted, is because the program doesn't realize you have entered anything if it is zero.
*******************

No, no graph... just a helper diagram (in the spirit of the picture in EVBEC Live)

It should work so long as you keep the picture ("helper.png", I believe) in the same folder as the html document.

*******************

Speaking of the diagram, I think a slight error in it caused Jimmy's problem: a muzzle-impact spacing of 100 means that the projectile's flight ended at a point 100 meters above the muzzle. Or when the projectile nosed over.

(the simulation ends when the projectile is under the impact point AND it is moving in a downwards direction)

So, Jimmy, simply enter a value of -100 meters if you want to simulate dropping a tater out of a building.

*******************

Oh, and the issue with the apogee tool-tip? Fixed that.
I had an apostrophe in the quote, so it wouldn't display, that's all...

I simply take the sine of the angle you enter and multiply it by the velocity: this calculates the vertical component of your velocity.
The vertical component of your velocity is then used in the calculations, completely ignoring the horizontal speed.

Yep, exactly correct. BTW, if you use the sine then straight up is a 90&deg; launch angle.

Yeah, the entered values in the "optional" section have to be above 0... which, as jimmy noted, is because the program doesn't realize you have entered anything if it is zero.

But it looks like you can fool it buy just entering a very small value, like 0.0001m/s for the muzzle velocity.

Tried the "-100" trick for the "Muzzle-impact spacing" value. Works like you said. I probably should have read the mouse-over description. I figured that distance was to take into account the height of the muzzle above the ground. So a 6' value would mean that the muzzle was 6' above the ground. Looks like you need to enter -6'.

If you use larger and larger magnitude negative numbers of the "Muzzle-impact spacing" you can estimate the terminal velocity from the mass, diameter and Cd of the ammo.

Now, what would be the velocity at ground level of a 0.38 cal pistol fired straight up. Would it be dangerous? Since the calc. probably won't properly handle a supersonic round you would probably need to model it as if the round was just dropped from a great height. Just need the mass, diameter and Cd of a 0.38 (and assuming it doesn't tumble).

Lets see, assume mass=130gr=8.4g, D=0.38"=0.965cm, Cd=0.3

Velocity at -1000 ft = 77m/s
Velocity at -10,000 ft = 79m/s

So it looks like a terminal velocity of ~79m/s, ~260 FPS.

Roughly 1~2% the KE the bullet had when it left the barrel.

I wonder how fast a person can throw a 0.38 slug?

Eh, I'm not so sure that one can model partly-horizontal launches that way. Let's examine a time step in which the projectile is launched at 30* above the horizontal at 100 m/s:

We'll define drag to be equal to (velocity in m/s)²
Basically, I cut the constants out of the equation. Still fully functional for this purpose.

Way 1:
(100m/s)² = 10,000
sin(30)*10,000 = 5,000 (downward drag units)

Way 2:
sin(30)*100 m/s = 50m/s
(50m/s)² = 2,500 (downward drag units)
******************

I expect that "way 1" is the proper way to do it... but the currently implemented system is analogous to the second method.

boilingleadbath wrote:Eh, I'm not so sure that one can model partly-horizontal launches that way. Let's examine a time step in which the projectile is launched at 30* above the horizontal at 100 m/s:

We'll define drag to be equal to (velocity in m/s)²
Basically, I cut the constants out of the equation. Still fully functional for this purpose.

Way 1:
(100m/s)² = 10,000
sin(30)*10,000 = 5,000 (downward drag units)

Way 2:
sin(30)*100 m/s = 50m/s
(50m/s)² = 2,500 (downward drag units)
******************

I expect that "way 1" is the proper way to do it... but the currently implemented system is analogous to the second method.

Velocity is a vector quantity so it can be split into two (or more) orthogonal components. I believe it is proper to split the velocity into the vertical and horizontal components before calculating the drag forces, so "Way 2" is the correct method. (See for example https://www.ac.wwu.edu/~vawter/PhysicsN ... ector.html)

horizontal velocity: v_x = v_muzzlecos(angle)
vertical velocity: v_y = v_muzzlesin(angle)
total velocity: v_muzzle = sqrt(v_x² + v_y²)

There are some problems with this approach, most notably the drag in the x and y directions is not the same for many projectile shapes.

Ignoring that problem, I believe this is how trajectories are usually handled unless a very high degree of accuracy is required.

Here is a more complete treatment that takes into account the spin and the cross-coupling between the various axis of flight.

The resident physics professor is asleep right now, so I'm going to turn to Dhall...

First off, launching a projectile at 409 fps (89* above horizontal) using the GGDT exterior ballistics tool is not equivalent to launching one at 818 fps (30*). Hang time, time to apogee, and the apogee in the latter case are much less than in the former.

Secondly, in <a href="http://www.spudfiles.com/spudtech_archive/viewtopic.php?t=15069&postdays=0&postorder=asc&highlight=ballistics&start=0">this</a> thread, hall says the following:

"Uh, no, [separating the velocity into its components, and then calculating drag] is NOT how it is usually done and in fact it does NOT work for non-spherical objects. "

"Nor do I but I was tired when I posted previously and was willing to <u>concede</u> that there may be a way to make [splitting the velocity into components] work for a spherical object (but even in my dead sleep I know it won't work for a non-spherical object). "
(underlining is mine)

"Sure, [Vertical drag = sin(angle)*velocity^2] works."

Thirdly, FORCE is also a vector quantity; it can be divided into orthogonal components too.
************************

If it turns out that I have to use a two-dimensional simulation for drag, I will probably either remove the angle option from the program or add a "headwind" (required) and a "range" (optional) input.

The latter option allows the following input pairs:
range-velocity (wonderfully accurate and easy to measure both inputs)
range-apogee (ain't going to be accurate)
range-hangtime (has potential)
range-Cd (not the best, comparable to apogee-Cd or HangTime-Cd)
**********************

I noticed that I haven't compiled a list like this for the existing options:

velocity-Cd (accurate, but subject to garbage in->garbage out)
velocity-hangtime (Easy to measure the inputs, fairly accurate)
velocity-Apogee (Somewhat more accurate then velocity-hangtime, given the same input precision. But measuring apogee bothersome.)
Cd-hangtime (slightly worse than velocity-hangtime, have to guess at Cd)
Cd-Apogee (better than Vel-Apogee, have to guess at Cd)
Hangtime-apogee (should be the worse of the bunch, plus the search algorithm doesn't work well)

I might get into this debate later, but for now, I'm not quite in the mood, so I'll wait for a while.

It looks like a very nice piece of work.
A slight comment might be that atmospheric pressure and humidity could be accounted for in the air density calculation, but that isn't a major issue.

It does however agree, almost to the letter*, with the LRC V3.0 (which I've still got to finish for a certain person), which does handle humidity and air pressure (as well as air density changes with projectile altitude), so the difference is fairly negligible.

*Agrees to within 0.5% on apogee and hang time for the simulation I did.

Boiling, ya, I think you (and DHall) are correct. You do need to calc the drag then split the drag into x and y components to calculate the affects on vx and vy. So you need to keep track of all three velocities.

Things get pretty wierd when you start to compare spherical shells with aerodyamically stable shells with spin stabilized shells.

Spherical is nice because the Cd and area in various directions is the same (assuming no spin).

An aerodynamically stable rounds nose over at appogee and are always pointed in the direction of maximum velocity.

A spin stabilized round always points in the same direction (as long as it is still spinning fast enough). Fired at a large launch angle it'll hit the ground butt first. Fired at a shallow angle off a cliff and the drag changes from being proportional to the frontal area when it still has a large horizontal velocity to being proportional to the sideal (?) area when drag has dropped the horizontal velocity enough and the significant velocity has become vertical.