SpudFiles

Those of you that read the "Desktop" topic might have noticed I've been back at the Ballistics Simulator.

Now, I've got some issues that need looking at if it's going to become a viable public release. I can work with them, but I'm trying to make it as simple to use as possible, and I know most of you don't share my excessive knowledge on the subject, so you'd probably find these issues more of a problem than I will.
I also probably won't know if what could be a problem either.

Suffice to say, good answers to the questions are in your interest.

~~~~~

First is the lift calculator. At the moment, it's very simplistic.

You enter in a percentage figure, and that tells the program what percentage of the projectile's weight is generated in lift at the muzzle velocity. So, 100% gives the projectile's weight in lift at the muzzle velocity, 200% twice that, 50% half the weight... you get the idea.

The problem here is that changing the muzzle velocity also changes the lift coefficient, which then makes it somewhat less than intuitive to model the effects of changes in solely the muzzle velocity.

Equally, the problem is that most people will have no idea about the lift co-efficient either, and they won't know if what they've entered is sane, useless, or ridiculous.

Ideas welcomed on making it easy, intuitive and able to accept changes in muzzle velocity without difficulty for the user. I do have one idea, but it's still ugly, and I'd rather not have to use it.

~~~~~

Next, I want to make sure the units system is solid, to get around the complaints about the SI units only that the last version used.
Anything unit you think really needs to be on this list, tell me. Inversely, anything on this list that you think really doesn't need to be, tell me that instead.

Length: Centimetres, Feet, Inches, Kilometres, Metres, Miles, Millimetres, Yards
Atmospheric Pressure: Atmosphere, Bar, Inches of Water, Inches of Mercury, Kilogram-force per square centimetre, Kilopascals, Millibar, Millimetres of Water, Millimetres of Mercury, Pascals, Torr
Mass: Grains, Grams, Kilograms, Ounces, Penny Weight, Pounds, Troy Ounces, Troy Pounds
Velocities: Feet per Second, Kilometres per Hour, Metres per Second, Miles per Hour
Temperatures: Celsius/Centigrade, Fahrenheit, Kelvin, Rankine
Energies: Foot Pound force, Joules
Angles: Degrees, Grads, Radians, "O'Clock" (And perhaps Compass Directions, if I can be bothered)
Latitude: Degrees
Small Areas: Square Centimetres, Square Inches, Square Millimetres
Air density: Kilograms per Cubic Metre, Pounds per Cubic Foot (This is an output, not an input, don't worry!)

~~~~~

I was considering posting a large list of variables I'm modelling and say "Hey, think I've missed anything obvious?" but I'm not going to do that, because if I've considered how the latitude at which a cannon is being fired affects the range, I think I might have considered enough.

Anyway, I would say I'm going to get back to coding, but I've got a meeting to go to now, so I won't say that yet.

One thing that pretty much stops me in my tracks when reading a post is small font. Now keep in mind if members abuse it there will be a crack down and rightfully so.

As for your calculator/s I hope they come with how to's/instructions, that will keep the simple questions to a minimum. It would be nice to be able to predict with some accuracy what is going to do what.

Thanks for all your hard work Ragnarok.

Edit: The list looks solid to me.

Lift calculator? You mean lift like the wings of an airplane have? So far I have not seen any projectiles with lift besides spherical projectiles affected by the magnus effect.
Maybe you should also insert a function for that.

Now that I think of it, a spin may also go to the side. Does your calculator also calculate the path in 3 dimensions, probably including wind speed?

~~~

Your unit system looks more then enough to me. Sounds like a very nice program to use. You will only have to find a user-friendly user interface to switch between these unit systems.

~~~

Well good luck! When can we expect a beta?

@jrrdw
Hold cntrl and use the scroll wheel of your mouse to change the text size of the whole page. (This is on firefox, I am not sure whether IE has the same function)
Also you could try viewing it on a larger screen, a lower resolution, a magnifying glass, or, have your eyes checked.

@jrrdw: Sorry, I didn't think that small text would be a problem. I generally shrink down any large lists so that they don't get too much in the way.

Yes, it will have a guide. However, I've a nasty feeling that the guide is going to take a horrible amount of time to write.

Now, it will offer a lot of accuracy, but here's the important bit - for the person who is prepared to give it the right input data. If you're just throwing random numbers at it, then it'll return the favour, and throw back equal garbage. The more accurate your input, the more the end result will mean. If you're just looking for a ball park figure, then this may be more than you need.

@psycix: Well, any projectile naturally generates a small amount of lift, but mostly, this is fairly negligible.

So, in generally, the Magnus effect is the main intention of the function what the function is for. However, given the fact that I doubt most people will know the Reynolds numbers, or angular velocity of their projectiles, it's easier to just model it with a simple number like that.

It does calculate in three dimensions, and like you suggest, you can also model the cant of the spin, but I doubt anyone will really have vast interest in that... well, unless of course, they're trying to hook their shots.

But then again, I'm giving the option to model the Coriolis effect and Earth curvature, so I'm probably the looney here. Still, believe it or not, these DO have a minor, but noticeable, effect on a project I'm planning.
In the end, this is going to start to make many commercial firearms ballistics simulators start to look like they've got a lack of features.

Actually, in the end, you could pick this up, and use it for regular firearms. The whole thing is, because spudguns are so widely varied in their design and intention, I have to build in all the different things people are likely to want it for.

The unit system is far from complex. It's just a drop down list next to the input on the main page. You click on it, select your option, and you're ready to go. Thing is, I just want to make sure it's nailed down properly and for that, I need to make certain it's got all the options people are likely to want.

Now, I don't know exactly when the beta will be available, but the chances of it will certainly drastically improve when I stop trying to model silly things. The good news is, I think I may be running out of silly things to model - which is in itself somewhat silly.

Heck, I might as well turn this into a kind of blog at the same time...

What I'm currently trying to do is sort out the stability controls for the program.

What this features does is tells it how the projectile is stabilised (well, duh...), for which there are currently three options: Unstablised, Spin stabilised, and Drag Stabilised, and each of these tells the program how to model the projectile's stability.

Unstablised assumes the projectile can tumble, and works out from the information the program is given, an average ballistic co-efficient for the projectile, which it then uses for all calculations, assuming that the tumbling of the projectile will be essentially random and roughly equal out along the way.

Spin stabilised fixes the projectile's orientation due to gyroscopic effects, then calculates the ballistic coefficient at each step of the calculation based on the relative direction of the air flow.

Drag stabilised changes the projectile orientation to match that of the airflow at each stage of the calculations, which actually makes it the most efficient ballistically, because it never presents the projectile's inefficient flanks to air flow.
However, that doesn't necessarily mean it gets the longest range.

Don't know how many of you will use the feature, but I certainly plan to.

Since I know that you are interested in accuracy, and the main key of accuracy is consistency; maybe you should have a function which allows to enter a range of values instead of a single one.

For example, as the magnus effect also diverts to the side, it would be nice if it could calculate all possible shots in all spin directions in one go.
Or when your projectiles are not 100% consistent (they never are unless you machine them very precisely.) Enter a range of projectile masses and see how much the results divert from each other.

Another thing that would be nice would be if I could enter a target size and distance, and it then returns the estimated hit percentage, assuming the aim is perfect.

Something I would LOVE to see ,if it's not already in there, is for there to be an input for muzzle height(not angle) and zero or <zero angle of firing...

These 2 items alone willhelp sort out other unknown variables of gun performance by allowing a perfectly horizontal shot towards a target of known distance, and using projectile drop to help sort actually projectile speed/muzzle velocity/ Cd, etc....

psycix wrote:Since I know that you are interested in accuracy, and the main key of accuracy is consistency; maybe you should have a function which allows to enter a range of values instead of a single one.

I have considered a "Tolerance" control - but the problem is, this would then take a minimum of three times the calculation time. Once to calculate it as given, once to calculate the worst case scenario, and once to calculate the best case scenario.
As well as that, it has the problem that it then requires three sets of output boxes, and I'm struggling to find the space for just one, without moving onto another sheet.

However, it would be possible to add some form of "Memory" to the program, where you press a button, and it puts a set of results aside into another sheet for for later comparison.

But that's more something to add after the first beta. Right now, I think the priority is making sure the raw basics work before I add frills, bells and whistles.

Anyway, the important thing is, that as far as my interest in accuracy, when I get around to it for those reasons, I'll be weighing each projectile in advance, and predicting the trajectory of each individual projectile on it's own and compensating for everything in advance of firing it.

Another thing that would be nice would be if I could enter a target size, and it then returns the estimated hit percentage, assuming the aim is perfect.

That's a far trickier prospect, because it's asking prediction of more than intentional or predictable effects.

However, there is going to be something that will predict POI on a target at a given range.

@ jeepkahn:It's actually already on there. I just happen to be crazy.

Actually, while I'm here, a semi-complete list of ballistic effects considered:
Drag; Variations in Drag vs. Mach number; Environmental conditions such as Pressure, Temperature, Humidity, Altitude, Latitude and Wind Speed/Direction; Thinning of altitude with height; Change of speed of sound with altitude; Magnus effect and other lift; Methods of stability; Earth Curvature; Coriolis effect (The ones in italics can be turned off if the user so desires.)

And of course the simple stuff, like velocity, projectile mass/diameter, firing height and firing angle.

Great news everyone! I've turned the Earth into a peanut!
(i.e. I've made a cock-up in the Earth radius calculations that means it's being modelled as peanut shaped.)

*SWEARWORDS*

Why not work from the calculations Joanna made in her launcher range calculator?
It accounted for wind speed/direction, altitude, drag coefficient and angle, and told you about recoil, range, peak height and energy/velocity.

Overall it seems to be doing a lot of what you want, except it's in a spreadsheet.

Biopyro wrote:Why not work from the calculations Joanna made in her launcher range calculator?

Essentially, I am using the same basic calculations, given that I need to cover the same core things like drag and gravity.
However, there were some mistakes in the ways those calculations were used (which, obviously, need correcting), and there are more things that people wanted added.

Some of those things may have been what I wanted added, given one of my main reasons for getting this all to work is that I intend to use the data it provides for a project which needs far more advanced features than what the original version provides.

Overall it seems to be doing a lot of what you want, except it's in a spreadsheet.

I'm currently working in a spreadsheet as well, given the relative simplicity that it allows me to work with but the major difference is that I'm doing the calculations in a macro, rather than as spreadsheet functions, which should make the use of it somewhat slicker - as well as heftily cutting the file size (original was closing on 5 megabytes. The new one should measure in a few hundred kilobytes instead.)

I may eventually do it as solely Visual Basic program, but that's for after it all works neatly in Excel.

Are you going to release this simulator for us to use?

maverik94 wrote:Are you going to release this simulator for us to use?

That's the plan. If it can be got to work smoothly, it will become a public release.

Rag

Have you considered hiding the more advanced options and inputs on a seperate tab? Something along the lines of a main tab with the basic info, good for people that aren't worried about more minor details and/or really don't know what appropriate values would be anyway. A second tab with the higher order affects, folks can fiddle with'm but probably shouldn't unless they really understand what they mean and what suitable values are.

On the subject of "tolerance" control, one possibility would be not to do mutliple calculations, instead just calculate the partial derivatives with respect to the various variables. That's getting pretty advanced but it would be really handy to have an output that says something like "a 10% change in your mass will result in a 20% (or whatever) change in range if all other variables are held constant". Of course, that means you (or the user) has to pick what the most important output is (range, muzzle velocity, KE at distance etc.). Probably more complex than you want to do but it would be neat.

The layout D_Hall used in GGDT and HGDT for the "sensitivity analysis" is a good way to go as well, and would be very useful.

Well, any projectile naturally generates a small amount of lift, but mostly, this is fairly negligible.

Not really. Any symetrical shape flying such that its long axis is aligned with the flight path won't generate any lift. It can't, everything is symetric. There must be some asymetry; in the round's shape, flight aspect or spin, to create lift. A typical drag stabilized round won't ever generate any lift. Or, it'll generate a minor amount of lift that is changing direction constantly as the round precesses (wobbles).

Yeah I agree, that most of those functions should be kept as an "avanced" option, getting an accurate result in average conditions seems the most important aspect.