Ballistic Program

[K2Ballistics]

A while back, Bryan Litz did a comparison of his solver, JBM, and the one I wrote (link in my sig), but the post might have gotten nuked when the forum software was upgraded. As expected, they were all pretty darn close because we all use the point mass method. However, all three of us used a slightly different method of integration - I stepped through distance, Litz stepped through time, and JBM used a variable step algorithm. Nonetheless, the differences were pretty small.

FYI, I also use a distance step. I wonder if Bryan has switched do a distance step as well.. The distance method is so much easier when presenting results as you usually want results at a known distance as opposed to a known time. I just eliminates an extra step/extrapolation.

I have also written (though it's not available publicly because it's a garish hack at the moment) a point mass solver that uses arbitrary drag functions. I think it is the simplest, most direct method possible. You seem to have gone a step beyond and actually tested some bullets, so here's a question: Given that we often see deviation from the standard drag functions at high velocity and near mach 1, is there a new standard drag function out there that will be a good enough approximation to real bullets so that we don't need custom drag functions for each bullet? G7 already comes very close - is a custom drag function for each bullet overkill?

That is an excellent question and is the holy grail of ballisticians world-wide. Unfortunately I just don't think it is out there... at least as long as we are stuck with solving the equations of motion. I mean a lot of our LR bullets can be classified as G5 or G7 like in their profile, but even these two behave very differently in the trans/sub sonic region. Each projectile is designed differently and as such has its own signature, thus I am resolved to test each on that I use. I think maybe the answer is enough of us investigating these functions and publishing the results....


Out of curiosity, what numerical integration method are you using?

 

[mouse07410]

Thanks to you as well

I find a lot of SGK's have a G5 like profile, but not always. I have had a mixed bag with SMK's. A lot are G7 like, but others have turned put to be more G5 like....hope that make sense.

Yeah, your description makes sense...

Well I can't run JBM with my drag functions so it is hard to get an apples to apples on this one. When I do comparison testing, I do so by putting a standard drag function into my engine with a modifier such that GuPoint and JBM are using simalar drag modeling. My goal here is to proof my solver by using the same inputs in both models. This accomplished, I use real world dope to proof my drag functions.

Ah, but my question had a more practical motive. I wanted to know if your solver with your custom curves agreed with JBM using its standard curves but adjusted via velocity-banded BC, at least within the supersonic range, hopefully down to transonic.

Off the cuff, I can absolutely say that I agree very closely with JBM in the supersonic and starting phase of transonic when using the same inputs.

Can I interpret it as "they agree - JBM with standard curves and GuPoint with custom curves - down to starting phase of transonic"?

We start to differ in late trans and subsonic when still using same inputs. We can start do differ quite a bit if I use my drag models compared to keeping a standard model in JBM. This does not always occur and is bullet dependent, of course.

Yes, this is understandable, and quite expected. I suspect (assuming my interpretation above is correct) that this was your main reason for writing your own solver? Getting something that's accurate down to subsonic at least for some bullets?

Still considering how to share results/data. I am not as hesitant about this as I am building software for the public. I just want to make sure whatever I release is absolutely correct... at least within the capabilities of my equipment and processes.

I understand perfectly. And must note that your equipment setup (AFAIK) is extremely rare. I'm aware of only two such efforts: by Bryan Litz who measured quite a few bullets and published "Applied Ballistics for Long Range Shooters", and by you. (Disclaimer: measurements done by Lapua and various Armed Forces are not counted here.)

I also would make you sign a waiver never to attend the same competition as me! LOL!

OK, OK, if you put it this way - I won't compete.

Till very recently, my injured back prevented me from even lifting a rifle, let alone shooting it. :-(

 

[mouse07410]

Is there a new standard drag function out there that will be a good enough approximation to real bullets so that we don't need custom drag functions for each bullet? G7 already comes very close - is a custom drag function for each bullet overkill?

That is an excellent question and is the holy grail of ballisticians world-wide. Unfortunately I just don't think it is out there... at least as long as we are stuck with solving the equations of motion. I mean a lot of our LR bullets can be classified as G5 or G7 like in their profile, but even these two behave very differently in the trans/sub sonic region. Each projectile is designed differently and as such has its own signature, thus I am resolved to test each on that I use. I think maybe the answer is enough of us investigating these functions and publishing the results....

My personal opinion - this issue can be addressed with banded BC. It should take a few banded BC's for the top speed, maybe a few for the rest of the supersonic range, maybe a few for subsonic - but plenty, maybe a lot of banded BC to cover the transonic range. The bands must not be equally spaced.

Then a standard curve could be used - it just doesn't get enough adjustments in the critical areas from a few equally-spaced banded BCs.

What do you think, guys?

 

[K2Ballistics]

Ah, but my question had a more practical motive. I wanted to know if your solver with your custom curves agreed with JBM using its standard curves but adjusted via velocity-banded BC, at least within the supersonic range, hopefully down to transonic.


Can I interpret it as "they agree - JBM with standard curves and GuPoint with custom curves - down to starting phase of transonic"?



[/I]

No, I am saying we have good agreement when running the same drag curves. Proof of solver was my goal. I proof my drag functions in the field.

 

[K2Ballistics]

My personal opinion - this issue can be addressed with banded BC. It should take a few banded BC's for the top speed, maybe a few for the rest of the supersonic range, maybe a few for subsonic - but plenty, maybe a lot of banded BC to cover the transonic range. The bands must not be equally spaced.

Then a standard curve could be used - it just doesn't get enough adjustments in the critical areas from a few equally-spaced banded BCs.

What do you think, guys?

Yes, but what you are doing at the end of the days is a custom curve. You have to do some type of testing to come up the bands.

FWIW, I always step thru this "banding" process when working up a curve. I always compare my curves to the standard curves G1 thru G8, to find the closest profile match and then look at where the standard curve needs to be modified to match the real world curve. This is what will utlimately further our knowledge of projectile flight.....identifying and categorizing the behavior of various projectiles. Without this piece - and actually solving the physical equations of motion - you are just manipulating math and fitting curves. I could care less about that, I want to know about projectiles.

 

[mouse07410]

Yes, but what you are doing at the end of the days is a custom curve. You have to do some type of testing to come up the bands.

Well, strictly speaking (and maybe splitting hairs & picking nits), once you start adding to that single BC that's supposed to represent the difference between a given projectile and the standard one - you're already customizing the curve. And even that single BC is determined by testing of a given bullet anyway...

FWIW, I always step thru this "banding" process when working up a curve. I always compare my curves to the standard curves G1 thru G8, to find the closest profile match and then look at where the standard curve needs to be modified to match the real world curve. This is what will utlimately further our knowledge of projectile flight.....identifying and categorizing the behavior of various projectiles. Without this piece - and actually solving the physical equations of motion - you are just manipulating math and fitting curves. I could care less about that, I want to know about projectiles.

I'm not sure I understand. Isn't fitting curves a direct result of understanding the behavior of various projectiles? As for categorizing - it would be great if common traits could be determined, but so far it seems that the one commonly agreed upon property is that all the projectiles behave differently once they hit the transonic...? :-(




Mouse
NRA Life Member Sent from my iPad using Tapatalk - now Free

 

[damoncali]

Out of curiosity, what numerical integration method are you using?

4th order Runge Kutta. But honestly, I used it because I knew it, and saw it recommended in a few places. I didn't give it much thought. I tend to think picking a good step size is more important than the integration method. Mine will blow up in weird cases - for example, very low muzzle velocities at very long range. You wind up with a step size that is far too large. But that problem does not show up for anything realistic. Still, it makes me wonder if an adaptive (or just smaller - computers are pretty fast these days) step size might be better for very long range - there could be a few inches of error in there in some cases, but I'm just speculating.

I just can't help but think that since our bullets look an awful lot alike (and not that much like the standard projectiles) that there is a better one size fits all drag function. But maybe not. Like much in the world of computers, data seems to be more important than algorithms here.

 

[damoncali]

My personal opinion - this issue can be addressed with banded BC. It should take a few banded BC's for the top speed, maybe a few for the rest of the supersonic range, maybe a few for subsonic - but plenty, maybe a lot of banded BC to cover the transonic range. The bands must not be equally spaced.

Then a standard curve could be used - it just doesn't get enough adjustments in the critical areas from a few equally-spaced banded BCs.

What do you think, guys?

If you take a banded BC to its logical conclusion, you wind up with a custom drag function.

A banded BC is nothing but an indirect way of tweaking the drag function. So why not do it directly? If you tweak the drag function, you are adjusting drag coefficients - something with a pretty clear physical meaning. When you tweak BC's by banding, you are using an incorrect drag coefficient and making up for it by using an incorrect BC. Mathematically, you may wind up at the same point, but you are losing meaning in the process.

This matters because if you had a bunch of custom drag functions for different bullets, you could compare them and gain an understanding of bullet design and how it impacts drag. With banded BC's you don't really have anything to look at (although you could reconstruct the drag function implied by banded BC's - but why do that?).

 

[damoncali]

I'm not sure I understand. Isn't fitting curves a direct result of understanding the behavior of various projectiles? As for categorizing - it would be great if common traits could be determined, but so far it seems that the one commonly agreed upon property is that all the projectiles behave differently once they hit the transonic...? :-(

No, fitting curves does not imply understanding. You can fit a curve by testing your rifle at various ranges and writing the results down. It will be perfect - better than any solver! But you won't have a clue why the bullets hit where they do.

Bullets do not behave as differently as some would have you think. Like many things in shooting, we tend to throw science out the window when it gets hard. "Every gun likes different bullets, they're like women." That sort of BS. Guns don't "like" anything. They can't make choices. It's all just engineering. You can figure it out.

 

[mouse07410]

[MENTION=50186]damoncali[/MENTION], I think I understand your point and agree with it.

I wonder (a) how much data about a specific bullet design is needed to derive its trajectory, and (b) how much the variations between individual bullets of the same manufacturer (or even of the same batch/lot) screw up these attempts to derive meaningful generalizations...

 

[Lowlight]

The biggest issue, that no computer can address is the Human Factor

Things that happen in a fixture cannot always be recreated when you put a shooter behind the rifle. How that round is released is a direct result of the person shooting it, how the recoil is managed, etc. That human factor cannot be figured in unless you go out and shoot it and than adapt that data to the computer. Its' why Spindrift doesn't work the same for everyone... the Doppler can tell you SD is 1 MOA in fixture, but then put a left handed shooter behind the rifle and it's wrong. Doesn't mean the SD the Doppler test saw was wrong, it means the solution to that question is wrong. Why because of the Human Factor. That is why, back in the day, ExBal from Gerald Perry had "Shooter's Drift" instead of SpinDrift...he asked you to shoot at 600 yards and measure your drift and then the computer used that factor. Smarter way of doing SD business if you ask me.

There are other things, like actual twist rate, just because they tell it is 1-12 doesn't mean it is... was it barrel 1 cut with a new tool, or barrel 100 last one before they changed tools. Was the metal harder or softer, did the tool drag, stutter, or slip. there are questions in there that never truly get answered. Like Muzzle Velocity, we want too, and need to reduce ES & SDs because we have no way of knowing what the actual velocity will be prior to pressing the trigger. We can use averages, and those work great in practical distances, but beyond it becomes tricky. Then add in that persons behind the trigger and all bets are all. They start using science to explain their lack of fundamentals... Let's face we're not all as nearly as good as we believe ourselves to be. That has consequences when trying to use a computer to determine where the bullet will impact.

it's good, but perfect will never happen. At least not as long as we have a Human Factor to contend with.

 

[slimJim2000]

I think there is a lot of truth to what lowlight said.

If you want ultimate accuracy then it’s hard to get better then Doppler radar data adjusted for environmental conditions. I think it’s only really practical for military applications where you have a fixed length barrel, twist and load.

I think that at least some of the focus on the transonic zone is coming from medium caliber F-class type shooters. The best option is to totally avoid the problem and stay above 1400 FPS and below 2.0 seconds time of flight.

 

[K2Ballistics]

No, fitting curves does not imply understanding. You can fit a curve by testing your rifle at various ranges and writing the results down. It will be perfect - better than any solver! But you won't have a clue why the bullets hit where they do.

Bullets do not behave as differently as some would have you think. Like many things in shooting, we tend to throw science out the window when it gets hard. "Every gun likes different bullets, they're like women." That sort of BS. Guns don't "like" anything. They can't make choices. It's all just engineering. You can figure it out.

Very well stated.

 

[K2Ballistics]

4th order Runge Kutta. But honestly, I used it because I knew it, and saw it recommended in a few places. I didn't give it much thought. I tend to think picking a good step size is more important than the integration method. Mine will blow up in weird cases - for example, very low muzzle velocities at very long range. You wind up with a step size that is far too large. But that problem does not show up for anything realistic. Still, it makes me wonder if an adaptive (or just smaller - computers are pretty fast these days) step size might be better for very long range - there could be a few inches of error in there in some cases, but I'm just speculating.

Agree with the step size observation.

Wish I could help you with your integration issues, but I am at a loss as i have no run into this directly. I can say I use pretty small steps as I am not so worried about speed. Have you tried reducing your step size for these weird cases?

 

[K2Ballistics]

Well, strictly speaking (and maybe splitting hairs & picking nits), once you start adding to that single BC that's supposed to represent the difference between a given projectile and the standard one - you're already customizing the curve. And even that single BC is determined by testing of a given bullet anyway...

I don't think we are is disagreement here, just a matter of semantics and how much manipulation before we call it custom.

I'm not sure I understand. Isn't fitting curves a direct result of understanding the behavior of various projectiles? As for categorizing - it would be great if common traits could be determined, but so far it seems that the one commonly agreed upon property is that all the projectiles behave differently once they hit the transonic...? :-(

damon answered this better than I could. My only addition is that I try to categorize purely from a research perspective in the hopes that I stumble upon that "ah-ha" moment.

 

[K2Ballistics]

The biggest issue, that no computer can address is the Human Factor

Absolutely. But, to drive faster, the race car driver needs the mechanic to figure out more efficient spoilers and engine timing sequences. To me that is what it is all about, pushing both the human factor part and the science part right up to the edge. I view them as going hand in hand, not separate.

 

[damoncali]

Agree with the step size observation.

Wish I could help you with your integration issues, but I am at a loss as i have no run into this directly. I can say I use pretty small steps as I am not so worried about speed. Have you tried reducing your step size for these weird cases?

The integration problem only shows up in ridiculous situations - like using a muzzle velocity of 30 fps and a step size of 1 yard. The drop at the thousandth yard blows up - which is pretty much expected since the bullet is basically traveling straight down that point, so the step size is totally inadequate. It's really not an issue, but it does make me wonder how much accuracy we give up in the integration step - especially at very long range. I've never played around with adjusting the step size to try to try to find out since things seem to work well enough with sane inputs.

 

[K2Ballistics]

The integration problem only shows up in ridiculous situations - like using a muzzle velocity of 30 fps and a step size of 1 yard. The drop at the thousandth yard blows up - which is pretty much expected since the bullet is basically traveling straight down that point, so the step size is totally inadequate. It's really not an issue, but it does make me wonder how much accuracy we give up in the integration step - especially at very long range. I've never played around with adjusting the step size to try to try to find out since things seem to work well enough with sane inputs.

Ok, gotcha. I wouldn't worry about those scenarios either.

I find diminishing returns on step size after awhile. As far as loss of accuracy due to integration, I think Bob McCoy talked about this some in his book. I can't recall off the top of my head at what point it became an issue, but I think you are well into dealing with non-laminar flow (subsonic) issues long before your integration methods fail you

 

[mouse07410]

Lowlight, you're certainly right about the human factor.

But are people (say, the majority) consistent enough in their erratic ways that one can insert "shooter drift" (say, instead of "spin drift") in the computer and get a correct trajectory (for that shooter) every time? I used to think that the main problem a shooter introduces is inconsistency, and/or things like flinching, jerking the trigger (and not exactly the same way every time either), etc. - which do not produce a repeatable deviation from the "ideal" POI?

 

[mouse07410]

Ok, gotcha. I wouldn't worry about those scenarios either.

I find diminishing returns on step size after awhile. As far as loss of accuracy due to integration, I think Bob McCoy talked about this some in his book. I can't recall off the top of my head at what point it became an issue, but I think you are well into dealing with non-laminar flow issues long before your integration methods fail you

Would you say that integrating by time would address the issue [MENTION=50186]damoncali[/MENTION] brought up? Are there disadvantages to integrating by time that prompted both you and [MENTION=50186]damoncali[/MENTION] to integrate by distance?

 

[K2Ballistics]

Would you say that integrating by time would address the issue [MENTION=50186]damoncali[/MENTION] brought up?

No. The step method has no impact on accuracy or stabilty. One is as good as the other as far as solution goes.

Once damon clarified his scenarios, I am not surprised they blew up. He was certainly pushing his solver to places it did not need to go i.e he was outside the boundaries of where RK4 was going to be able to converge on a solution given his time steps and other coding parameters. Mine may do the same, I never bothered to push it where he did.

Are there disadvantages to integrating by time that prompted both you and [MENTION=50186]damoncali[/MENTION] to integrate by distance?

The main disadvantage to time integration is due to the way shooters use a ballistics program. I'll give an example...If you use a time step, then you have a table of solutions at the times you selected for steps....e.g. TOF = .437s, .457s, .477s and so on. The trouble starts because you and I want a solution at 705 yards. Well, if your solution TOF's now correspond to 704.2 yards and 704.77 yards and 705.38 yards you have to perform any extra extrapolation calculation to get the answers in a form that you and I want, namely at 705 yards.

The loss of accuracy is negligible since the steps are so small. It is more of a convenience issue for the programmer having to do some extra work.

 

[slimJim2000]

The primary problem I see with more advanced ballistics models such as fluid dynamics, Six degrees of freedom is that they need hard to obtain inputs such as center of pressure and center of gravity.

What kind of inputs does your algorithm take?

 

[damoncali]

The stuff we're talking about is a 3dof model (aka "point mass"), and the only difficult to obtain input is the drag function. It's the same method that JBM and others use.

 

[slimJim2000]

Three degrees of freedom is not enough. The transonic zone is messy.

 

[K2Ballistics]

Three degrees of freedom is not enough. The transonic zone is messy.

LOL. Hopefully you have some contacts over at BRL to get us a copy of one.

 

[slimJim2000]

LOL. Hopefully you have some contacts over at BRL to get us a copy of one.

What’s BRL? I use 6 degrees of freedom all the time in my day job. It’s not that complex and it’s how the real world works.

I am just saying these problems have already been solved to a large degree. Ballistics is just stuck in the 1800s.

It just takes a lot of vector calculus.



Edit: (BRL) must stand for Ballistic Research Laboratory. Sorry I am not a defense industry type ;p
Frankly when I visited Lockheed's faculty last time they were still using 1980s hardware.

 

[K2Ballistics]

What’s BRL? I use 6 degrees of freedom all the time in my day job. It’s not that complex and it’s how the real world works.

I am just saying these problems have already been solved to a large degree. Ballistics is just stuck in the 1800s.

Writing a 6dof solver is certainly within the capabilities of many of us here on this board. In fact, more than one have dabbled. The problem for the garage modeler are the projectile parameters required to achieve meaningful results are difficult to define. Many must be determined in controlled lab/chamber settings. This is unsurmountable for the part time modeler with no .gov grants.

Some, most notably McCoy, have presented models and math to determine the required parameters, but they really are rough approximations to the real thing. To me, it is rather counter-intuitive to work up a piece of art like a 6-dof model only to run it with gross inputs and achieve inferior results than you would have from a 3-dof.

It just takes a lot of vector calculus.

While I can certainly appreciate the point, I'm of the thought that ballistics involves a wee bit more than just vector math, especially in the subsonic region.....

 

[damoncali]

Three degrees of freedom is not enough. The transonic zone is messy.

That depends entirely on what your goals are.

 

[slimJim2000]

Writing a 6dof solver is certainly within the capabilities of many of us here on this board. In fact, more than one have dabbled. The problem for the garage modeler are the projectile parameters required to achieve meaningful results are difficult to define. Many must be determined in controlled lab/chamber settings. This is unsurmountable for the part time modeler with no .gov grants.

Some, most notably McCoy, have presented models and math to determine the required parameters, but they really are rough approximations to the real thing. To me, it is rather counter-intuitive to work up a piece of art like a 6-dof model only to run it with gross inputs and achieve inferior results than you would have from a 3-dof

Point particle in a 3D Euclidean space should not be that hard. Or that different from mass point but gives a better mathematical frame work.

While I can certainly appreciate the point, I'm of the thought that ballistics involves a wee bit more than just vector math, especially in the subsonic region.....

Like what? Honestly Geometric algebra seems over kill. Quaternions you will need to avoid gimbal lock maybe. 6 DOF is not some magical thing you can have many models with 6 DOF some that are very simple.

The real problem to me seems to be that model drag curves don’t work that great.

 

[K2Ballistics]

Point particle in a 3D Euclidean space should not be that hard. Or that different from mass point but gives a better mathematical frame work.

Again, writing an actual 6DOF model, while tedious, is not overly difficult for someone knowledgeable in math and physics. Determining the projectile parameters needed to run it are for the most part experimentally derived.. I don't have a flow chamber in my garage. If I did, I would be able to determine lift force coefficient, Magnus force and moment coefficients, pitch damping coefficient, spin damping coefficient, rolling moment coefficient, overturning moment coefficient, etc for each and every projectile I shoot....Then, I could justify writing a 6DOF model. Until then, I work with what I have, which fortunately is more than I need.

Like what? Honestly Geometric algebra seems over kill. Quaternions you will need to avoid gimbal lock maybe. 6 DOF is not some magical thing you can have many models with 6 DOF some that are very simple.

I think you misunderstood my comment which had nothing to do with 6DOF. Partly, my comment was directed towards studi of the subsonic region. Turbulent flow modeling involves very little algebra and a lot more that I can cover in a single post. If you are really inclined, you can get started here: Turbulent Flows 00 edition, Stephen B. Pope (9780521598866) - Textbooks.com. Great book. The other part was directed towards what ballisticians, or any scientist for that matter, really do which is experiment, experiment, experiment. For every hour I send doing "vector math", I quite literally have 500 more booked in study, research and experimentation. Given your stated background, I am certain you can appreciate what I am trying to say.

The real problem to me seems to be that model drag curves don’t work that great.

Not sure which drag curves you a referring to. If you are talking about the standard drag functions derived by Gavre, Ingalls and BRL then I would say that these functions work great for what they are intended (previous TIC comments aside). They just are limited in that they do not adequately address every projectile we now have available to us and the ranges we are now pushing them to. On a personal level, this is why my work is more heavily directed towards research and experimentation with projectiles and less and less with modeling.

 

[damoncali]

On a practical note, we still use G1 drag functions for most everything, and G7 for some others. That gets us pretty far. But we have not yet even cataloged the actual drag function of most of the bullets on the market. That is a tremendous amount of work, and the most obvious and easiest thing to research at the moment. Certainly more important than trying to figure out all the other coefficients (magnus, spin damping, etc) for any given round, which is a lot harder and more expensive to do.

As I've said before, ballistics calculations are a solved problem. The hard problem is getting the data to put into the calculations. For where we are now, getting accurate data for even a 3DOF model is still a largely unsolved problem.

 

[LastShot300]

This was so far a nice thread, but beyond all these questions on the current state of the ballistics theory, I think we should not miss the practical aspect of it. I mean, at the end of the day, shooters only care on predictions made by the different packages, and so far, only two (Patagonia and FFS) have been acknowledged as the most accurate under real ELR conditions (which of course implies all the errors discussed here), and none of them run on a PM solver. So while this is discussion on Point Mass is good, implying in some way, that it's the end of all ends is not matched by the real experience of many.

On 6DOF, I work with them a lot, and to be honest, the accuracy gain even at ELR is pretty marginal, at least for shoulder-fired weapons, which is what we care about only.

 

[slimJim2000]

It’s interesting about the drag curves.

When I programed my code I personally picked. The Pejsa model my program uses a modified Pejsa model. It’s not bad especially in the supersonic range however by 3000 yards it’s off by inches compared to Doppler radar. However it will get you well part 1000 yards.

Still it seems like the best model for my requirements.
1: Blindingly fast allows for simulation of many projectiles.
2: Does not use a BC so that it can work with projectiles of unknown BC (tank shell etc.), which seems to be part of the original goal of the model as Pejsa mentions tanks.

 

[slimJim2000]

It’s interesting about the drag curves. Research is definitely the hardest part.

When I programed my code I personally picked the Pejsa model. My program uses a modified Pejsa model. It’s not bad especially in the supersonic range however by 3000 yards it’s off compared to Doppler radar. However it will get you well past 1000 yards.

Still it seems like the best model for my requirements.
1: Blindingly fast allows for simulation of many projectiles and real time.
2: Does not use a BC so that it can work with projectiles of unknown BC (tank shell etc.), which seems to be part of the original goal of the model as Pejsa mentions tanks.
3: I would have liked a model that can deal with rockets but ended up using a different code path for this. Massively simplified 6 DOF rigid body (discrete math) which I have honestly not even tested.

 

[LastShot300]

It’s interesting about the drag curves.

When I programed my code I personally picked. The Pejsa model my program uses a modified Pejsa model. It’s not bad especially in the supersonic range however by 3000 yards it’s off by inches compared to Doppler radar. However it will get you well part 1000 yards.

Still it seems like the best model for my requirements.
1: Blindingly fast allows for simulation of many projectiles.
2: Does not use a BC so that it can work with projectiles of unknown BC (tank shell etc.), which seems to be part of the original goal of the model as Pejsa mentions tanks.

Well, but those inches at 3000 yards, could be a lot of things. Sometime ago DTA made a 3080 yards test, and the differences yielded by the mentioned programs against PM solvers left them in the dust. And that's somehing we cannot ignore, clearly using the same inputs, so the difference lies under the hood. How many inches you got of difference at 3K? Could be an interesting exercise in order to understand the inputs. As pointed out by Lowlight we are dealing with unaccountable human errors and mechanical errors as well.

 

[slimJim2000]

Pejsa original code was off by like 100 meters at 3000 meters. He used a 30.06 152 Gr M2 bullet as his reference projectile as an option or you can use a Pejsa type curve. For his ballistics curve which he relates to a G1 curve. I don’t think his code was doing this but just extending the supersonic curve out if you did not input all the necessary curve date. Pejsa allows a lot of fine tuning in his model.

The drag curve becomes linear in the Trans and subsonic ranges. This causes problems I made several adjustments to Pejsa. In the supersonic zone I use a Pejsa type curve, In the transonic zone and beyond I used a modified curve still linear but based roughly off of the 300 Gr. SMK. I actually made a number of modifications to Pejsa. This helped a lot across the board.

This is with a 300 gr SMK. Out to 1500 meters it matched radar very well.

Remember this is in meters and so it’s farther then yards. My program only has targets to 1200 yards which is well within the accuracy of modified Pejsa.


Note some of the environmental conditions may be different.
1500 meters, 1640.42 yards
Total drop (m) radar 30.035
Total drop (m) modified Pejsa 30.136117233017 (about 4 inches off)(Note that this is with an unturned slope factor. )
Total drop (m) original Pejsa (don’t remember his software only works on windows xp)

3000 meters, 3280.84 yards
Total drop (m) radar at 241.735
Total drop (m) modified Pejsa 248.710677305196
Total drop (m) original Pejsa at 154 ( don’t remember his software only works on windows xp but it was way off, but he allows a lot more fine tuning then I allow. This value was from only inputting a starting slope factor and velocity data)


Pejsa past the supersonic range seems to have problems. Modified Pejsa also has the velocity of an m1 carbine at 500 yards as 100 FPS to 75 FPS less than G1.

 

[LastShot300]

Pejsa original code was off by like 100 meters at 3000 meters. He used a 30.06 152 Gr M2 bullet as his reference projectile. For his ballistics curve which he relates to a G1 curve. I don’t think his code was doing this but just extending the supersonic curve out if you did not input all the necessary curve date. Pejsa allows a lot of fine tuning in his model.

The drag curve becomes linear in the Trans and subsonic ranges. This causes problems I made several adjustments to Pejsa. In the supersonic zone I use a Pejsa type curve, In the transonic zone and beyond I used a modified curve still linear but based off of the 300 Gr. SMK. I actually made a number of modifications to Pejsa. This helped a lot across the board.

This is with a 300 gr SMK. Out to 1500 meters it matched radar very well.

Remember this is in meters and so it’s farther then yards. My program only has targets to 1200 yards which is well within the accuracy of modified Pejsa.


Note some of the environmental conditions may be different.
1500 meters, 1640.42 yards
Total drop (m) radar 30.035
Total drop (m) modified Pejsa 30.136117233017
Total drop (m) original Pejsa (don’t remember his software only works on windows xp)

3000 meters, 3280.84 yards
Total drop (m) radar at 241.735
Total drop (m) modified Pejsa 248.710677305196
Total drop (m) original Pejsa at 154 ( don’t remember his software only works on windows xp but it was way off, but he allows a lot more fine tuning then I allow. This value was from only inputting a starting slope factor and velocity data)


Pejsa past the supersonic range seems to have problems. Modified Pejsa also has the velocity of an m1 carbine at 500 yards as 100 FPS to 75 FPS less than G1.

Thanks for the data, quite interesting and also quite different than the predictions obtained by DTA in their ELR test.

I don't have the thread at hand, but I can recall a difference between the actual drop and prediction of about 9 inches at 3080 yards (Patagonia & FFS), while JBM was off by several yards. All programs with the same input. I guess it all comes down to how those programs have been modified in a similar fashion like you did. Thanks again!

 

[slimJim2000]

Thanks for the data, quite interesting and also quite different than the predictions obtained by DTA in their ELR test.

I don't have the thread at hand, but I can recall a difference between the actual drop and prediction of about 9 inches at 3080 yards (Patagonia & FFS), while JBM was off by several yards. All programs with the same input and accounting. I guess it all comes down to how those programs have been modified in a similar as you did. Thanks again!

It’s not surprising they could be off a few inches compared to radar. As I said earlier in the thread I think the easiest way to be able to develop a super accurate ballistics calculator would be to simple to use Doppler radar adjusted for environmental conditions.

Not mathematically appealing but easy.

Pejsa is very easy to over fit. I tried not to do this. So that it works for most projectiles. Even stuff like an m1 carbine at least passably well and work within a 1200 to 1500 yard envelope.

 

[K2Ballistics]

Sorry to have cluttered up the thread.

 

[mouse07410]

3000 meters, 3280.84 yards
Total drop (m) radar at 241.735
Total drop (m) modified Pejsa 248.710677305196

I don't have the thread at hand, but I can recall a difference between the actual drop and prediction of about 9 inches at 3080 yards (Patagonia & FFS), while JBM was off by several yards. All programs with the same input. I guess it all comes down to how those programs have been modified in a similar fashion like you did.

It seems to say that your modified Pejsa is off by about 7 meters (6.975m to be specific)? And JBM (a Point Mass solver) was off by several yards? I can understand the advantage of FFS that was off by 9 inches, but 7 meters? I guess FFS and Patagonia don't have to worry yet about an upcoming strong competitor?

As I said earlier in the thread I think the easiest way to be able to develop a super accurate ballistics calculator would be to simple to use Doppler radar adjusted for environmental conditions.

Not mathematically appealing but easy.

I'm glad at least one person finds obtaining Doppler radar data - especially down to subsonic range - easy (though not particularly appealing ).

Would you mind getting and posting here the Doppler data for the following bullets to begin with:

• .308: 168gr AMAX, 178 AMAX, 208 AMAX
• .338: 250gr SMK, 300gr SMK, 285gr BTHP (Hornady)

I'm sure many including myself would thank you.

Sorry to have cluttered up the thread.

Well, I for one am grateful for your participation, and am looking forward to see both your drag curves, and your solver.

 

[slimJim2000]

Sorry to have cluttered up the thread.

You seem to be very knowledgeable. If you get a good model developed will you write a paper?

It seems to say that your modified Pejsa is off by about 7 meters (6.975m to be specific)? And JBM (a Point Mass solver) was off by several yards? I can understand the advantage of FFS that was off by 9 inches, but 7 meters? I guess FFS and Patagonia don't have to worry yet about an upcoming strong competitor?

Well it’s possible to get better results if you have multiple tuned drag curves. Pejsa allows this by just changing a few numbers. With a single drag curve Pejsa after modification ended up giving results similar to a G7 curve which takes G1 or velocity data as inputs preferably velocity data. It also works for a wider range of projectiles in the supersonic zone then G7 because you can change the slope factor.

You could have a Pejsa type model that is tuned by caliber or whatever and it tries to select an appropriate drag curve. It still feels kind of artificial. The linear part of the drag curve is the main problem but after tuning it would be possible to get very good results.

Like I said I had other reasons for picking Pejsa initially namely for comparing historic tank cannons in the supersonic range.

Also I think DTI was using a .375 CheyTac at 3080 yards. Hard to compare with .338 LM at 200 yards further.