Alright, I'll tip my hand a bit...

[D_Hall]

jared is right.. i got 100m/s (333fps) more than on evbec..
can be a good thing to

mabe that was because of the burst disk stuff.

The burst disc definately matters. Have you tried it with the disc set to 0 psi?

[Jared Haehnel]

Oops I hadn't thought of that good point sorry

Thanks again for the program and all the work you do in the name of spudding... 8)

[sniperjosh]

Can ya just type over the old value rather than deleting it?

yep, no problems. I'm gonna try to get a couple of gauges tomorrow, and hopefully do some proper testing, I'm interested to see how accurate the current model is

[Fnord]

Yeah, but think about it a sec... a 10 oz 1" diameter projectile? That's lead ball territory.

Actually a 1" diameter lead ball only weighs 4 oz

I think the "burst disk failure" thing needs some work; I know the piston valve I have will open at exactly 60 psi at 6x, and it seems to underestimate the performance quite a lot with that number.

But...
If the initial mix pressure is not treated as zero then it would open at 135 psi. Which is it?

[D_Hall]

Yeah, but think about it a sec... a 10 oz 1" diameter projectile? That's lead ball territory.

Actually a 1" diameter lead ball only weighs 4 oz

I think the "burst disk failure" thing needs some work; I know the piston valve I have will open at exactly 60 psi at 6x, and it seems to underestimate the performance quite a lot with that number.

But...
If the initial mix pressure is not treated as zero then it would open at 135 psi. Which is it?

I'm not sure I follow your question so I'll just say that the disc will go when the pressure differential between the chamber and the barrel is 60 psi.

So... Roughly speaking, a 6X mix is initially at 88.2 psi (14.7*6). The barrel is at 14.7 psi (ambient), so the pressure differential right off the bat is 73.5 psi. Ergo, a 60 psi burst disc won't even allow you to fuel the gun without blowing the disc (if it's not giving an error, thanks, you just found one... doesn't hurt the math at all, but it should be listed as a warning or something).

With the disc going immediately and no combustion currently modeled in the barrel, I would expect extremely low velocity numbers.

[Fnord]

Yeah, I don't get an error/warning when I set the burst pressure below the mix pressure.

[clide]

Setting the burst disc to 0 with a reasonable gun gives me
ERR: Proj never cleared muzzle
WRN: Barrel unnecessarily long

[jimmy101]

Dave

Looking good, you've made a lot of progress.

Some suggestion and questions, a few might even be worthwhile.

1. How about putting the version number in the GUI somewhere? Do you keep a version number, and/or date, as a variable in the code? Might as well show it on the GUI. It also helps when someone posts a screen shot, every body else can tell what version they used. I find it easier to keep the version number in the code instead of keeping it as part of the program named (like GGDT4.0.exe).

2. Is the friction value for the ammo the static or dynamic friction? Or is it similar to GGDT where it is both?

3. What time step are you using? (I assume you are modeling everything at discrete times steps instead of as the integral.) Have you looked at how the model responds to different time steps? In my model, I've found the smaller the gun the smaller the time step needs to be. For "typical" sized guns I usually use a 20uSec time step.

4. It would be real handy if you could add the "% combustion" to the Y-axis pull down for the graph. Since there isn't a comparable concept in a pneumatic gun there isn't any reason for GGDT to have had it, but in a combustion gun it is nice to know if, and when, combustion completed. Also nice to know how long after the burst disk ruptured the combustion completed. So, how about adding it to the Y-axis pull down for the graph?

5. Let me be the first to take your model and do something with it that it wasn’t designed for. If I try to model a 1X gun without a burst disk, and using the burst disk pressure as the static friction, and assuming the friction input is the dynamic friction, and comparing to my standard gun (3"x11" chamber, single central spark, 2"x30" barrel, 80g spud, chrono muzzle velocity ~330FPS) the model gives a muzzle velocity of ~140FPS. That's off by a factor of more than 2. I suspect this is caused by the model not doing combustion in the barrel. Actually, I suspect the problem is a bit more general in that it isn't correctly modeling combustion in the chamber or the barrel after the spud has started to move. In a 1X no-burst-disk gun the projectile starts to move very early in the combustion process, probably after only 10~20% of the fuel has been burned. If I set the burst disk pressure up near the peak propane-air closed chamber pressure the velocity is up in the 360 FPS range, which looks to me to be a pretty reasonable estimate of what it should be. Including the burst disk essentially forces the model to burn all (or most) of the fuel before the spud starts to move, thus avoiding the problem of modeling the combustion process as the projectile is moving.

I'm not sure if it'll help you but here is how I handle combustion as the projectile is moving.

All of my calculations are done relative to the fraction of the chamber volume that has been burned. Before the spud starts to move, the pressure and the temperature in the chamber (average values) at a particular time are simply the fraction of fuel burned (the burned volume over the chamber's total volume) interpolated into the Tmax and Pmax for closed chamber combustion of propane. So, at 50% combustion Ti=0.5(Tmax-Tinit)+Tinit and Pi=0.5(Pmax-Pinit)+Pinit. (I'm ignoring the heat loss component of the model.) This seems to work well for a closed chamber model.

The problem comes when the spud starts to move. As the spud moves this causes the flame fronts to move as well. For example, if in a single time step the spud moves such that the total chamber volume increased by 1% then the flame fronts have to move as well. They must move such that the fraction of the new chamber volume that has been burned is the same as the fraction before the spud movement was calculated. I look at it as if there are three volumes in the chamber; (1) the unburned volume near the breech, (2) the burned volume and (3) the unburned volume on the muzzle end. For this example, all three volumes need to increase by 1% so that the fraction burned stays unchanged. (Fuel can't be "unburned" just because the total chamber volume has increased.) That means the breech end flame front moves towards the muzzle. The muzzle end flame front also moves towards the muzzle, and it moves more than the breech end flame front. The relative movements of the two fronts has to take into account the chamber and barrel diameters and has to end up with all three volumes increasing by 1%. A side affect of the movement of the two flame fronts is that the center of the combustion zone moves as well. So, in the next time step the flame front movement caused by combustion is measured from this new combustion center. Basically, you can look at it as if the projectile is sucking the flame fronts towards the muzzle. In my model this seems to work pretty well. Of course, the math gets to be a PITA, especially when the flame front actually moves into the barrel.

So, there are two things moving the flame fronts; the (flame front speed)(time step) product and the movement of the spud itself.

This goes back to a question you posed a few weeks ago, "what is the flame front speed measured relative to?". In a closed chamber (or a gun with a high pressure burst disk) the flame speed is simply the combustion speed. In a gun with the ammo moving during the combustion process the apparent flame front speed, what you would see if you could video the combustion process, is a combination of the burn speed and the movement of the fronts caused by the movement of the projectile.

The other thing I do is that once the spud starts to move the Tmax and Pmax have to be rescaled to take into account the expansion. In a gun in which the fuel is still burning when the projectile is moving the temperature and pressure will never reach the closed chamber Tmax and Pmax values.

You've probably already thought of all this, but what the heck, sometimes it helps to hears someone else's take on a complex model.

[D_Hall]

First a comment regarding the post above the one I'm addressing; IE, the post where the projectile didn't move... Very odd. I'll definately have to take a peek at that one to see what's going on that's so insanely different.

1. How about putting the version number in the GUI somewhere? Do you keep a version number, and/or date, as a variable in the code?

Yeah, it's stored as a variable and will actually show up if you hit the "about" pulldown. You've a good point though. No reason for it not to show up in the top of the window.

2. Is the friction value for the ammo the static or dynamic friction? Or is it similar to GGDT where it is both?

Identical to GGDT (a cut & paste of that particular piece of code).

3. What time step are you using? (I assume you are modeling everything at discrete times steps instead of as the integral.) Have you looked at how the model responds to different time steps?

I'm using 10 microseconds. Same as GGDT uses, btw (GGDT requires the small steps to reasonably model the valves).

4. It would be real handy if you could add the "% combustion" to the Y-axis pull down for the graph.

Point taken. I'll look into it once the basic model is running right.

5. Let me be the first to take your model and do something with it that it wasn’t designed for. If I try to model a 1X gun without a burst disk, and using the burst disk pressure as the static friction, and assuming the friction input is the dynamic friction, and comparing to my standard gun (3"x11" chamber, single central spark, 2"x30" barrel, 80g spud, chrono muzzle velocity ~330FPS) the model gives a muzzle velocity of ~140FPS. That's off by a factor of more than 2. I suspect this is caused by the model not doing combustion in the barrel. Actually, I suspect the problem is a bit more general in that it isn't correctly modeling combustion in the chamber or the barrel after the spud has started to move. In a 1X no-burst-disk gun the projectile starts to move very early in the combustion process, probably after only 10~20% of the fuel has been burned.

I'm aware of the issues regarding early movement and how not modeling combustion in the barrel will affect velocity. I believe I mentioned low velocities in the original post in the thread... I didn't mean 5% low. I meant LOW.

The problem comes when the spud starts to move. As the spud moves this causes the flame fronts to move as well.

I'm well aware.

I look at it as if there are three volumes in the chamber; (1) the unburned volume near the breech, (2) the burned volume and (3) the unburned volume on the muzzle end. For this example, all three volumes need to increase by 1% so that the fraction burned stays unchanged. (Fuel can't be "unburned" just because the total chamber volume has increased.) That means the breech end flame front moves towards the muzzle. [...] Of course, the math gets to be a PITA, especially when the flame front actually moves into the barrel.

I considered this approach for a long time and eventually went in a different direction as it seemed like the math would get nasty when multiple ignition points where thrown into the mix. In the end I went with a different approach that is admittedly less accurate for the single point ignition scenario but should be more flexible.

This goes back to a question you posed a few weeks ago, "what is the flame front speed measured relative to?". In a closed chamber (or a gun with a high pressure burst disk) the flame speed is simply the combustion speed. In a gun with the ammo moving during the combustion process the apparent flame front speed, what you would see if you could video the combustion process, is a combination of the burn speed and the movement of the fronts caused by the movement of the projectile.

Again, well aware. The model I'm using attempts to take into account...

1) Basic flame speed.
2) Flame acceleration due to turbulent flow (modeled as a function of l/D).
3) Movement of the macroscopic local gas mass.

The other thing I do is that once the spud starts to move the Tmax and Pmax have to be rescaled to take into account the expansion. In a gun in which the fuel is still burning when the projectile is moving the temperature and pressure will never reach the closed chamber Tmax and Pmax values.

Obviously. This phenom is at the heart and soul of GGDT.

[DYI]

Great work Dave. My current project is looking better and better (couldn't model it on EVBEC due to that programs ridiculous C:B ratio restrictions).

While we're on the topic, I've been wondering something about the GGDT's range calculator: Why is it that, for light and fast moving projectiles (i.e. airsoft BBs) it sometimes spits out a negative range? Because for some reason I think that an airsoft round leaving the barrel at 1km/s is going to go a few hundred feet forward before it stops.

[D_Hall]

While we're on the topic, I've been wondering something about the GGDT's range calculator: Why is it that, for light and fast moving projectiles (i.e. airsoft BBs) it sometimes spits out a negative range? Because for some reason I think that an airsoft round leaving the barrel at 1km/s is going to go a few hundred feet forward before it stops.

Can you give me an example?

[SpudFarm]

woha even this beta is REALLY accurate!
i set the burst pressure of the disk at 18bar on my small hybrid and i got 327m/s ! chrony read 327.7m/s


BEST PROGRAM EVER

[pat123]

Great job
but what does ignitor data number mean?

edit: is it the number of spark gaps

[DYI]

Example:

Gun using:
-1x12" chamber
-.3" porting barrel sealing piston valve with 2 ounce piston, 0.25" porting,
1ci pilot volume
-848.3 psi hydrogen at 80 degrees fahrenheit
-0.2401" x 72" barrel
-0.24", 0.2 gram projectile

Predicted muzzle velocity: 3 250 fps.
Predicted maximum range using drag coefficient of 0.4 (perfect sphere I believe): -1 feet

There must be some problem there.

It would be great if there was some way to take pictures of GGDT outputs that was easier than actually photographing it with a digicam and then uploading it to Photobucket.

[pat123]

I found one other thing I kept everything exactly the same except i changed the mix. At 1x it says 346 ft/s and at 3X it says 277ft/s. wouldn't 3x be alot faster?