ramjet vehicle performance estimation tool
Moderator: Mike Everman

 Posts: 12
 Joined: Sat Nov 24, 2007 3:14 am
 Antipspambot question: 0
 Location: Audubon, NJ, USA
 Contact:
ramjet vehicle performance estimation tool
I am developing a simple but hopefully useful Excel spreadsheet to help me in my attempt to build a selfsustaining ramjet. (It will be boosted up to speed by a rocket, so it will be launched vertically.) I'm no expert at any of this, but I'm doing the best I can with what I know.
Right now it basically works like any crude rocket altitude predictor  you enter the rocket's diameter, weight, Cd, and the motor's thrust curve, and it shows you graphs of the speed, altitude, etc. The Cd value for a rocket can easily be guessed at by using another tool like RockSim, or finding the Cd of a craft similar to the one you're designing. So far so good. Then the fun stuff: it takes parameters like the number of ramjets, ramjet inlet and outer diameters, amount of fuel, fuel type, burn time, etc, and it tries to figure about out how it might perform. (You can also give it an initial velocity to simulate firing it out of a cannon or whatever.)
I am attaching the current version of the spreadsheet. (Let me remind everyone that it is very much a work in progress, and it has lots of silly things I need to fix, like inconsistency of units.) Right now my biggest question is this: what is the best way to estimate the drag caused by a ramjet engine? For the rocket part, "force of drag = 0.5*(air density)*Cd*(frontal area)*(velocity)^2" works pretty well. But when I use frontal area values based on Decker's designs, I can not for the life of me get the engine to sustain itself. I think I need to find a more accurate way to measure this drag. (The example graphed in the spreadsheet uses artificiallyselected ramjet dimensions to reduce drag, and it still doesn't sustain itself.)
Does anyone have any suggestions for this drag problem? I could try building a scale model and launching it a couple of times on a rocket engine with no fuel to the ramjet, and then play with Cd values and frontal area numbers until I got RockSim and my spreadsheet to mostly agree.... it seems like there should be a better way though. Another thing I've thought of is trying to use a free CFD program (maybe OpenFOAM?) to get a handle on this. Right now I've never done any CFD before so I don't know much about how good of an idea this is, or what kind of time investment it will require to learn. Any input?
For those interested, here's the approach I started with for the simulator: first I put together a simple rocket simulator spreadsheet (google for the formulas, nothing fancy). Then I took Decker's graph of thrust vs diffuser inlet area, and found an equation that approximates it. I then used an atmospheric model (from NASA's site, nothing fancy again) and used that to derate the thrust of the ramjet based on altitude. Another fun thing the spreadsheet does is it calculates how much air you would scoop up on your flight, and how much of the selected fuel type you would need for stoichiometric combustion. (You can then feed this back into the weight of the vehicle or the amount of fuel you carry to refine your design.) I'd love to write this as a Java applet or program at some point, but let's be honest, I don't need another project right now...
Thanks for any ideas guys!
Right now it basically works like any crude rocket altitude predictor  you enter the rocket's diameter, weight, Cd, and the motor's thrust curve, and it shows you graphs of the speed, altitude, etc. The Cd value for a rocket can easily be guessed at by using another tool like RockSim, or finding the Cd of a craft similar to the one you're designing. So far so good. Then the fun stuff: it takes parameters like the number of ramjets, ramjet inlet and outer diameters, amount of fuel, fuel type, burn time, etc, and it tries to figure about out how it might perform. (You can also give it an initial velocity to simulate firing it out of a cannon or whatever.)
I am attaching the current version of the spreadsheet. (Let me remind everyone that it is very much a work in progress, and it has lots of silly things I need to fix, like inconsistency of units.) Right now my biggest question is this: what is the best way to estimate the drag caused by a ramjet engine? For the rocket part, "force of drag = 0.5*(air density)*Cd*(frontal area)*(velocity)^2" works pretty well. But when I use frontal area values based on Decker's designs, I can not for the life of me get the engine to sustain itself. I think I need to find a more accurate way to measure this drag. (The example graphed in the spreadsheet uses artificiallyselected ramjet dimensions to reduce drag, and it still doesn't sustain itself.)
Does anyone have any suggestions for this drag problem? I could try building a scale model and launching it a couple of times on a rocket engine with no fuel to the ramjet, and then play with Cd values and frontal area numbers until I got RockSim and my spreadsheet to mostly agree.... it seems like there should be a better way though. Another thing I've thought of is trying to use a free CFD program (maybe OpenFOAM?) to get a handle on this. Right now I've never done any CFD before so I don't know much about how good of an idea this is, or what kind of time investment it will require to learn. Any input?
For those interested, here's the approach I started with for the simulator: first I put together a simple rocket simulator spreadsheet (google for the formulas, nothing fancy). Then I took Decker's graph of thrust vs diffuser inlet area, and found an equation that approximates it. I then used an atmospheric model (from NASA's site, nothing fancy again) and used that to derate the thrust of the ramjet based on altitude. Another fun thing the spreadsheet does is it calculates how much air you would scoop up on your flight, and how much of the selected fuel type you would need for stoichiometric combustion. (You can then feed this back into the weight of the vehicle or the amount of fuel you carry to refine your design.) I'd love to write this as a Java applet or program at some point, but let's be honest, I don't need another project right now...
Thanks for any ideas guys!
 Attachments

 ramjet calcs.xls
 very much in development!
 (322.5 KiB) Downloaded 578 times

 Posts: 1063
 Joined: Mon Jun 05, 2006 4:28 pm
 Antipspambot question: 0
 Location: Brisbane, Australia
 Contact:
Dave I have to say this is phenomenal work, for only a few hours at it.
I think, that its a shame no more people have downloaded it. There was a massive great ramjet challenge on a while ago, which Eric beat the pants off us generating shock diamonds and some crazy amount of thrust, everyone was building little things and he came up with a monster that just smashed the piss outta everyone
Anyway, I think i'll be going back to my pulserams now too soon, and I'll be getting plenty more stainless in a few days to make that LPR, for nothing, like I said I would, I just want VIDEOS! And I want to see that rocket in front of it ignited whilst its running, all that stuff too! Anyway looking forward to it. Drop me a line, james.
I think, that its a shame no more people have downloaded it. There was a massive great ramjet challenge on a while ago, which Eric beat the pants off us generating shock diamonds and some crazy amount of thrust, everyone was building little things and he came up with a monster that just smashed the piss outta everyone
Anyway, I think i'll be going back to my pulserams now too soon, and I'll be getting plenty more stainless in a few days to make that LPR, for nothing, like I said I would, I just want VIDEOS! And I want to see that rocket in front of it ignited whilst its running, all that stuff too! Anyway looking forward to it. Drop me a line, james.

 Posts: 4934
 Joined: Fri Oct 31, 2003 7:25 am
 Antipspambot question: 0
 Location: santa barbara, CA
 Contact:
Yeah, it's a good start.
Mike
__________________________
Follow my technical science blog at: http://mikeeverman.com/
Get alerts for the above on twitter at: http://twitter.com/mikeeverman
__________________________
Follow my technical science blog at: http://mikeeverman.com/
Get alerts for the above on twitter at: http://twitter.com/mikeeverman

 Posts: 12
 Joined: Sat Nov 24, 2007 3:14 am
 Antipspambot question: 0
 Location: Audubon, NJ, USA
 Contact:
determining drag model  feedback requested
Ok, here's what I'm thinking right now as a way to determine a drag force model empirically. Any suggestions are appreciated!
I (or somebody else) put together a tool that reads in rocket motor thrust curves (such as from thrustcurve.org) along with flight data in the form of altitude (or acceleration) vs time, along with the mass of the rocket and propellant. (The program/tool is either explicitly told when in the flight data the motor is ignited, or it could maybe try to detect it.) By taking the difference of altitude at different samples the acceleration could be calculated. Acceleration over a sample's time period could be used to calculate the net force (motor thrust + gravity + drag force). Subtracting the net force and gravity from the assumed motor thrust curve should give you the force of drag as it changes over time. More flights would result in more accurate data to account for variations from motor to motor.
Right now I'm thinking maybe a Java applet, with a field where you can paste the contents of a RASP file right off of thrustcurve.org. You enter the weight of your rocket (not including the rocket motor), and paste either acceleration or altitude data vs time. The program then spits out a graph of drag force vs time. Potentially you could enter a frontal area and it would tell you the corresponding Cd.
A rocket with a mockedup ramjet engine attached could be flown a couple of times to find the drag force vs time. Then the ramjet engine could be removed and the rocket flown again, and comparing the two graphs you could find the drag force (or Cd) caused by the ramjet engine alone. Doing this for multiple scales could help you come up with a model of ramjet dimensions vs drag force at different speeds. Finally, these graphs could be compared to Decker's graph of thrust/speed/diffuser size to see if it could overcome drag and gravity. The numbers will speak for themselves.
Anybody have any thoughts? I want to start on this but if anybody knows about something similar, or sees a hole in my plan, by all means stop me! Maybe tomorrow night I'll be able to get started.
Dave
I (or somebody else) put together a tool that reads in rocket motor thrust curves (such as from thrustcurve.org) along with flight data in the form of altitude (or acceleration) vs time, along with the mass of the rocket and propellant. (The program/tool is either explicitly told when in the flight data the motor is ignited, or it could maybe try to detect it.) By taking the difference of altitude at different samples the acceleration could be calculated. Acceleration over a sample's time period could be used to calculate the net force (motor thrust + gravity + drag force). Subtracting the net force and gravity from the assumed motor thrust curve should give you the force of drag as it changes over time. More flights would result in more accurate data to account for variations from motor to motor.
Right now I'm thinking maybe a Java applet, with a field where you can paste the contents of a RASP file right off of thrustcurve.org. You enter the weight of your rocket (not including the rocket motor), and paste either acceleration or altitude data vs time. The program then spits out a graph of drag force vs time. Potentially you could enter a frontal area and it would tell you the corresponding Cd.
A rocket with a mockedup ramjet engine attached could be flown a couple of times to find the drag force vs time. Then the ramjet engine could be removed and the rocket flown again, and comparing the two graphs you could find the drag force (or Cd) caused by the ramjet engine alone. Doing this for multiple scales could help you come up with a model of ramjet dimensions vs drag force at different speeds. Finally, these graphs could be compared to Decker's graph of thrust/speed/diffuser size to see if it could overcome drag and gravity. The numbers will speak for themselves.
Anybody have any thoughts? I want to start on this but if anybody knows about something similar, or sees a hole in my plan, by all means stop me! Maybe tomorrow night I'll be able to get started.
Dave

 Posts: 1063
 Joined: Mon Jun 05, 2006 4:28 pm
 Antipspambot question: 0
 Location: Brisbane, Australia
 Contact:
Drag model.
Dave thats an excellent idea. Nothing beats hard data, its a fact. A mock up of the engine would atleast allow you to work out how much thrust is required to overcome the amount of drag thats being produced, then all you have to know is an approximate thrust of the ramjet, and how beneficial it will be. Remember to calculate the added weight of fuel and the engine itself in your acceleration calcs. I got your email too by the way, responding shortly.
I love it.
I love it.

 Posts: 12
 Joined: Sat Nov 24, 2007 3:14 am
 Antipspambot question: 0
 Location: Audubon, NJ, USA
 Contact:
Re: determining drag model, HELP!!
Merry Christmas! Please excuse my usual longwindedness:
So I have been spending a bit of time putting together a program for using empirical altimeter data to determine the Cd vs Mach number of a vehicle. I've got a really good start but I'm hitting some glitches and hoped somebody could help me track them down.
Here's what I have: my program (DragFinder) takes in the mass and frontal area of the vehicle, RASP file (contains rocket motor thrust curve, total motor mass and propellant mass), and altimeter data (currently altitude vs time). It then attempts to compute a number of things. Currently I am using simulation data from RockSim rather than a real altimeter data file just so I can have good clean data to test my algorithms against before trying it on real data. The program resamples the motor data and the flight data to an arbitrary fixed sample rate of your choice, using linear interpolation to find the inbetween values.
Here's the status of the various fields it calculates so far:
 velocity: compares fairly well to what RockSim calculates. Not too worried that I'm doing it wrong.
 acceleration: the numbers aren't as close as I'd like, particularly on ignition, but overall they are pretty good. I'm finding it by taking (current velocity  previous velocity) / (current time  previous time). The values are fairly jittery though, more so than would be expected from just rounding errors and such (the data is all stored in Java "double" data types). (Note that in the example data, at around 3 seconds the accelerations should go negative as the drag overpowers the thrust. RockSim apparently only shows the magnitude of the acceleration, so it appears to spike back up.) It appears to me as though the altitude data points themselves are just jittery enough that these artifacts come out. Maybe it has to do with how RockSim rounds the altitude values, and the error compounds twice when going from altitude to acceleration...? Seems kind of unlikely.
 thrust: seems to match up to every decimal place with RockSim, yay! Clearly we're both using linear interpolation.
 mass: values are reasonably close, RockSim's algorithm for figuring mass from thrust must be slightly more complicated but the differences seem to be small. Not likely a significant source of error.
 mach number: a couple of specific points were run through a calculator on NASA's website and matched up perfectly with DragFinder, so I am fairly confident that given correct altitude and velocity numbers these will be correct. As it is, they're not far off of RockSim's numbers.
 Fnet (not provided by RockSim as a reference): net force acting on the vehicle. My assumption is that, from f=ma, net force should be just vehicle mass * overall vehicle acceleration as calculated from the altimeter data.
 Fdrag: this one confuses me a bit. My assumption is that in addition to the f=ma description above for Fnet, one could also use Fnet = Fthrust + Fgravity + Fdrag. Since Fthrust and Fgravity (vehicle mass * g) are known, subtracting them from the previously calculated Fnet should yield the drag force. If I use RockSim's values for acceleration and mass, Fdrag matches up VERY closely. Unfortunately when I use the Fnet calculated from the altitude values, the numbers bounce all over the place (like the acceleration only worse). With the exception of the initial blip which lasts several samples, DragFinder's values DO tend to float around the correct values, as you can see by comparing the two attached graphs. When filtered like this, the two programs agree reasonably well.
 Cd: from Fd = 0.5*rho*Cd*A*V^2, then Cd = Fd / (0.5 * rho * A * V^2). Seems to produce jittery but otherwise sensible numbers during the coasting phase of flight, but boost and apogee seem pretty bad. Presumably much of this is caused by the jittery Fdrag values.
So, any ideas on how to improve this? I can of course apply some smoothing on the input and output data to help with the jitters, but I'm hoping to find the real root of the problem and kill it. Overall I'm pretty excited about the program right now, and I'm looking forward to conducting some drag experiments to find out how draggy some ramjet designs really are!
Btw once I've got a few more fixes in the program I'd be glad to post it somewhere for public use. Thanks for any help!!
So I have been spending a bit of time putting together a program for using empirical altimeter data to determine the Cd vs Mach number of a vehicle. I've got a really good start but I'm hitting some glitches and hoped somebody could help me track them down.
Here's what I have: my program (DragFinder) takes in the mass and frontal area of the vehicle, RASP file (contains rocket motor thrust curve, total motor mass and propellant mass), and altimeter data (currently altitude vs time). It then attempts to compute a number of things. Currently I am using simulation data from RockSim rather than a real altimeter data file just so I can have good clean data to test my algorithms against before trying it on real data. The program resamples the motor data and the flight data to an arbitrary fixed sample rate of your choice, using linear interpolation to find the inbetween values.
Here's the status of the various fields it calculates so far:
 velocity: compares fairly well to what RockSim calculates. Not too worried that I'm doing it wrong.
 acceleration: the numbers aren't as close as I'd like, particularly on ignition, but overall they are pretty good. I'm finding it by taking (current velocity  previous velocity) / (current time  previous time). The values are fairly jittery though, more so than would be expected from just rounding errors and such (the data is all stored in Java "double" data types). (Note that in the example data, at around 3 seconds the accelerations should go negative as the drag overpowers the thrust. RockSim apparently only shows the magnitude of the acceleration, so it appears to spike back up.) It appears to me as though the altitude data points themselves are just jittery enough that these artifacts come out. Maybe it has to do with how RockSim rounds the altitude values, and the error compounds twice when going from altitude to acceleration...? Seems kind of unlikely.
 thrust: seems to match up to every decimal place with RockSim, yay! Clearly we're both using linear interpolation.
 mass: values are reasonably close, RockSim's algorithm for figuring mass from thrust must be slightly more complicated but the differences seem to be small. Not likely a significant source of error.
 mach number: a couple of specific points were run through a calculator on NASA's website and matched up perfectly with DragFinder, so I am fairly confident that given correct altitude and velocity numbers these will be correct. As it is, they're not far off of RockSim's numbers.
 Fnet (not provided by RockSim as a reference): net force acting on the vehicle. My assumption is that, from f=ma, net force should be just vehicle mass * overall vehicle acceleration as calculated from the altimeter data.
 Fdrag: this one confuses me a bit. My assumption is that in addition to the f=ma description above for Fnet, one could also use Fnet = Fthrust + Fgravity + Fdrag. Since Fthrust and Fgravity (vehicle mass * g) are known, subtracting them from the previously calculated Fnet should yield the drag force. If I use RockSim's values for acceleration and mass, Fdrag matches up VERY closely. Unfortunately when I use the Fnet calculated from the altitude values, the numbers bounce all over the place (like the acceleration only worse). With the exception of the initial blip which lasts several samples, DragFinder's values DO tend to float around the correct values, as you can see by comparing the two attached graphs. When filtered like this, the two programs agree reasonably well.
 Cd: from Fd = 0.5*rho*Cd*A*V^2, then Cd = Fd / (0.5 * rho * A * V^2). Seems to produce jittery but otherwise sensible numbers during the coasting phase of flight, but boost and apogee seem pretty bad. Presumably much of this is caused by the jittery Fdrag values.
So, any ideas on how to improve this? I can of course apply some smoothing on the input and output data to help with the jitters, but I'm hoping to find the real root of the problem and kill it. Overall I'm pretty excited about the program right now, and I'm looking forward to conducting some drag experiments to find out how draggy some ramjet designs really are!
Btw once I've got a few more fixes in the program I'd be glad to post it somewhere for public use. Thanks for any help!!
 Attachments

 Graph of drag force (Newtons) vs time taken from RockSim. This data is purely simulated, and so should be the baseline for the drag numbers calculated by DragFinder.
 FdragVsTimeRockSim.jpg (27.58 KiB) Viewed 11042 times

 Graph of drag force (Newtons) vs time as produced by DragFinder. DragFinder used as input the altitude values from RockSim, along with some other parameters. DragFinder was designed to analyze real flight data to determine drag empirically.
 FdragVsTimeDragFinder.jpg (42.28 KiB) Viewed 11038 times

 DragFinder vs RockSim.xls
 Excel Spreadsheet containing data from DragFinder (first tab) and RockSim (second tab).
 (798 KiB) Downloaded 387 times
Last edited by dgsharp on Sat Dec 29, 2007 4:44 am, edited 1 time in total.

 Posts: 3716
 Joined: Tue Dec 07, 2004 6:51 pm
 Antipspambot question: 0
 Location: 41d 1' N 80d 22' W
Re: determining drag model, HELP!!
Hi Dave,
I'm having a merry Christmas, and I hope you are, too.
You are asking for help, so I am going to pitch in my 2 cents.
It is unclear to me if you are incorporating the following, so I
am merely bringing it to your attention.
1. the equation
FD = CD × ½ × rho × V² × A
is fine for incompressible flow over a body  e.g. water flows
or slow air flows.
Remember though,
CD = f(Re)
or the drag coefficient is not a constant, it is a function of the
Reynolds number. It changes with change in Reynolds number.
2. If you are entering the compressible flow regime (which I think
you are with a ramjet) you are going to have to consider compressiblity
or free surface effects in your discussion of the drag force.
CD = f(Re, Fr, M)
Again, the drag coefficient is not a constant. For this case, it is
a function of not only the Reynolds number, but also the
Froude number and the Mach number.
This adds complexity, but is surmountable.
Cheers!
I'm having a merry Christmas, and I hope you are, too.
You are asking for help, so I am going to pitch in my 2 cents.
It is unclear to me if you are incorporating the following, so I
am merely bringing it to your attention.
1. the equation
FD = CD × ½ × rho × V² × A
is fine for incompressible flow over a body  e.g. water flows
or slow air flows.
Remember though,
CD = f(Re)
or the drag coefficient is not a constant, it is a function of the
Reynolds number. It changes with change in Reynolds number.
2. If you are entering the compressible flow regime (which I think
you are with a ramjet) you are going to have to consider compressiblity
or free surface effects in your discussion of the drag force.
CD = f(Re, Fr, M)
Again, the drag coefficient is not a constant. For this case, it is
a function of not only the Reynolds number, but also the
Froude number and the Mach number.
This adds complexity, but is surmountable.
Cheers!

 Posts: 12
 Joined: Sat Nov 24, 2007 3:14 am
 Antipspambot question: 0
 Location: Audubon, NJ, USA
 Contact:
Re: determining drag model, HELP!!
Hi WebPilot, thanks for the reply! Having a merry Christmas here too. (Oh man, free time... Gotta love it.)
> 1. the equation
>
>FD = CD × ½ × rho × V² × A
>
>is fine for incompressible flow over a body  e.g. water.
>
>Remember though,
>
>CD = f(Re)
>
>or the drag coefficient is not a constant, it is a function of the
>Reynolds number. It changes with change in Reynolds number.
It's kind of you to assume I knew! I actually don't know much about aerodynamics at all beyond the most intuitive basics, so I'll have to apologize for asking silly questions.
I've seen the equation used on the following two websites for rocket/ramjet stuff. This led me to believe that they were not necessarily what NASA would use, but that they should give me ballpark estimates. Let me know if you have any thoughts on this.
http://my.execpc.com/~culp/rockets/rckt_sim.html
http://www.altaccel.com/arla/arlaram.htm
The fact that the Cd isn't constant shouldn't pose a problem on its own for my program since it doesn't aim to spit out a single number, but rather drag estimates for all the data points found in the flight data. However, if you are correct (and you probably are), my Cd values themselves would be incorrect (though potentially still within the ballpark). However, the drag force numbers (rather than Cd) I come up with ought to be accurate, since I am finding them directly from mass and acceleration. If we assume the drag measurements are correct, a fullscale mockup of a ramjet should have the same drag as a fullscale real ramjet during portions of the flight envelope that are at the same speed and altitude.
The questions, then, are: 1) how do we scale our values up so we can use smaller mockups for our drag measurements, and 2) how do we use the data we've gathered at one set of speeds and altitudes in order to estimate drag at some other speed and altitude combination?
For question 1: it seems as though we could just linearly scale up with cross sectional area. For instance, if I perform drag measurements on a ramjet, and then strap two identical ramjets together to double the thrust, the area would double and one would expect the drag to double with it. Is this an oversimplification? (I don't need to get to the moon, I just want estimates that are good enough to help me develop a working ramjet.)
For question 2: this seems more tricky. I was hoping to come up with a graph of mach number vs Cd (as many rocket simulators produce) and plug that in to my rocket simulator. Maybe I could just try mach number vs drag force directly (since the vehicle simulator I put together uses the same drag equation, so it would be using the Cd incorrectly as well)? Or am I better off just biting the bullet and figuring out what to make of your new information and incorporating that into DragFinder as well as my vehicle simulator? (Frankly I don't know much about Reynolds numbers, and nothing about Froude numbers.)
>2. If you are entering the compressible flow regime (which I think
>you are with a ramjet) you are going to have to consider compressiblity
>or free surface effects in your discussion of the drag force.
Would this be less of an issue subsonic? If so, that's too bad it's not more generic but I'm planning on starting out subsonic anyway so maybe this is still fine for my purposes right now.
>CD = f(Re, Fr, M)
What I need is a real set of equations that I can then translate into code, or at least a description broken down into terms I can make sense of. I don't suppose you have any links you could point me towards?
Thanks for the thoughts!
Dave
> 1. the equation
>
>FD = CD × ½ × rho × V² × A
>
>is fine for incompressible flow over a body  e.g. water.
>
>Remember though,
>
>CD = f(Re)
>
>or the drag coefficient is not a constant, it is a function of the
>Reynolds number. It changes with change in Reynolds number.
It's kind of you to assume I knew! I actually don't know much about aerodynamics at all beyond the most intuitive basics, so I'll have to apologize for asking silly questions.
I've seen the equation used on the following two websites for rocket/ramjet stuff. This led me to believe that they were not necessarily what NASA would use, but that they should give me ballpark estimates. Let me know if you have any thoughts on this.
http://my.execpc.com/~culp/rockets/rckt_sim.html
http://www.altaccel.com/arla/arlaram.htm
The fact that the Cd isn't constant shouldn't pose a problem on its own for my program since it doesn't aim to spit out a single number, but rather drag estimates for all the data points found in the flight data. However, if you are correct (and you probably are), my Cd values themselves would be incorrect (though potentially still within the ballpark). However, the drag force numbers (rather than Cd) I come up with ought to be accurate, since I am finding them directly from mass and acceleration. If we assume the drag measurements are correct, a fullscale mockup of a ramjet should have the same drag as a fullscale real ramjet during portions of the flight envelope that are at the same speed and altitude.
The questions, then, are: 1) how do we scale our values up so we can use smaller mockups for our drag measurements, and 2) how do we use the data we've gathered at one set of speeds and altitudes in order to estimate drag at some other speed and altitude combination?
For question 1: it seems as though we could just linearly scale up with cross sectional area. For instance, if I perform drag measurements on a ramjet, and then strap two identical ramjets together to double the thrust, the area would double and one would expect the drag to double with it. Is this an oversimplification? (I don't need to get to the moon, I just want estimates that are good enough to help me develop a working ramjet.)
For question 2: this seems more tricky. I was hoping to come up with a graph of mach number vs Cd (as many rocket simulators produce) and plug that in to my rocket simulator. Maybe I could just try mach number vs drag force directly (since the vehicle simulator I put together uses the same drag equation, so it would be using the Cd incorrectly as well)? Or am I better off just biting the bullet and figuring out what to make of your new information and incorporating that into DragFinder as well as my vehicle simulator? (Frankly I don't know much about Reynolds numbers, and nothing about Froude numbers.)
>2. If you are entering the compressible flow regime (which I think
>you are with a ramjet) you are going to have to consider compressiblity
>or free surface effects in your discussion of the drag force.
Would this be less of an issue subsonic? If so, that's too bad it's not more generic but I'm planning on starting out subsonic anyway so maybe this is still fine for my purposes right now.
>CD = f(Re, Fr, M)
What I need is a real set of equations that I can then translate into code, or at least a description broken down into terms I can make sense of. I don't suppose you have any links you could point me towards?
Thanks for the thoughts!
Dave

 Posts: 3716
 Joined: Tue Dec 07, 2004 6:51 pm
 Antipspambot question: 0
 Location: 41d 1' N 80d 22' W
Even for slow gas flows, M < 0.3, Cd varies with Re
Ok, let's start over. For now, you need to spend some time and
understand what the Reynolds and Mach numbers are all about.
For gas velocities of M<0.3, the flow can be treated as incompressible.
If it's higher then you have to address compressibility.
Even for slow flows, CD varies with Re.
I borrowed this image from a bicycle rider:
See, you have to first compute the Reynolds number and then figure
out the CD. This can be coded in intervals. Forget the
overall equation.
REALIZE: there is a rho (or gas density) in the Reynolds number and
this varies with altitude!
Re, Fr, and M are all dimensionless parameters.
But I think it's already been done and can be found in the literature.
I seem to remember recently seeing on my hard drive a paper on drag.
If I find it again, I'll send it your way.
understand what the Reynolds and Mach numbers are all about.
For gas velocities of M<0.3, the flow can be treated as incompressible.
If it's higher then you have to address compressibility.
Even for slow flows, CD varies with Re.
I borrowed this image from a bicycle rider:
See, you have to first compute the Reynolds number and then figure
out the CD. This can be coded in intervals. Forget the
overall equation.
REALIZE: there is a rho (or gas density) in the Reynolds number and
this varies with altitude!
I would use the Buckingham Pi theorem and use dimensionless parameters.Dave wrote: The questions, then, are: 1) how do we scale our values up so we can use
smaller mockups for our drag measurements, and 2) how do we use the
data we've gathered at one set of speeds and altitudes in order to
estimate drag at some other speed and altitude combination?
Re, Fr, and M are all dimensionless parameters.
But I think it's already been done and can be found in the literature.
I seem to remember recently seeing on my hard drive a paper on drag.
If I find it again, I'll send it your way.

 Posts: 12
 Joined: Sat Nov 24, 2007 3:14 am
 Antipspambot question: 0
 Location: Audubon, NJ, USA
 Contact:
Re: drag
Ok, my program now calculates Reynolds numbers vs time for input flight data. For the characteristic length I went ahead and used the frontal area as suggested by the link below, but let me know if you have any better ideas for that (another one of the links further down in this post seems to suggest that frontal area should be just fine). Now, what to do with those Reynolds numbers?
http://www.altaccel.com/arla/arlaram.htm
That graph from the bicycle website shows the equation for Cd (the same drag equation I was using, just rearranged) and also makes separate mention of the Reynolds number on that graph, but the Reynolds number isn't found in the drag equation. If you can point me towards a drag equation (or the pieces of one, or whatever) that bridges this gap that would be great.
>For gas velocities of M<0.3, the flow can be treated as incompressible.
Ok. I'd hoped it was a little higher, since I keep seeing mention of Mach 0.8:
http://web.syr.edu/~smdemar/rocketdrag.html
>See, you have to first compute the Reynolds number and then figure
>out the CD. This can be coded in intervals. Forget the
>overall equation.
I'm trying to figure this out and I'm getting more confused. I was under the impression that the Cd would vary with mach number, but it's basically a magic fudge factor that compensates for all the other factors like viscosity and geometry. I haven't seen anything that suggests that there's a different drag equation for supersonic flow, only that the Cd has to change. But my approach attempts to measure the drag force almost directly, and so the Cd just falls out of the drag equation, magically taking everything into account. Here's another couple of links that seem to support what I thought I was doing:
http://www.grc.nasa.gov/WWW/K12/airplane/drageq.html
http://www.grc.nasa.gov/WWW/K12/airplane/dragco.html
>REALIZE: there is a rho (or gas density) in the Reynolds number and
>this varies with altitude!
Luckily I've been computing air density as a function of altitude since the beginning. Same with mach number and temperature. RockSim appears to calculate gravity dynamically but I haven't bothered with that yet.
I'm also not getting any references to the Froude number. I'm seeing Wikipedia call it "the hydrodynamic equivalent of the Mach number". Can't figure out what it would do for me in my situation.
>But I think it's already been done and can be found in the literature.
>
>I seem to remember recently seeing on my hard drive a paper on drag.
>If I find it again, I'll send it your way.
That would be appreciated as always! Thanks again, and sorry for all the silly questions!
Dave
http://www.altaccel.com/arla/arlaram.htm
That graph from the bicycle website shows the equation for Cd (the same drag equation I was using, just rearranged) and also makes separate mention of the Reynolds number on that graph, but the Reynolds number isn't found in the drag equation. If you can point me towards a drag equation (or the pieces of one, or whatever) that bridges this gap that would be great.
>For gas velocities of M<0.3, the flow can be treated as incompressible.
Ok. I'd hoped it was a little higher, since I keep seeing mention of Mach 0.8:
http://web.syr.edu/~smdemar/rocketdrag.html
>See, you have to first compute the Reynolds number and then figure
>out the CD. This can be coded in intervals. Forget the
>overall equation.
I'm trying to figure this out and I'm getting more confused. I was under the impression that the Cd would vary with mach number, but it's basically a magic fudge factor that compensates for all the other factors like viscosity and geometry. I haven't seen anything that suggests that there's a different drag equation for supersonic flow, only that the Cd has to change. But my approach attempts to measure the drag force almost directly, and so the Cd just falls out of the drag equation, magically taking everything into account. Here's another couple of links that seem to support what I thought I was doing:
http://www.grc.nasa.gov/WWW/K12/airplane/drageq.html
http://www.grc.nasa.gov/WWW/K12/airplane/dragco.html
>REALIZE: there is a rho (or gas density) in the Reynolds number and
>this varies with altitude!
Luckily I've been computing air density as a function of altitude since the beginning. Same with mach number and temperature. RockSim appears to calculate gravity dynamically but I haven't bothered with that yet.
I'm also not getting any references to the Froude number. I'm seeing Wikipedia call it "the hydrodynamic equivalent of the Mach number". Can't figure out what it would do for me in my situation.
>But I think it's already been done and can be found in the literature.
>
>I seem to remember recently seeing on my hard drive a paper on drag.
>If I find it again, I'll send it your way.
That would be appreciated as always! Thanks again, and sorry for all the silly questions!
Dave

 Posts: 3716
 Joined: Tue Dec 07, 2004 6:51 pm
 Antipspambot question: 0
 Location: 41d 1' N 80d 22' W
Re: drag
Dave,
You ask a lot of questions. I don't know if I can answer them all.
I haven't had time to look over this link.
http://www.altaccel.com/arla/arlaram.htm
But I did look over this one:
http://web.syr.edu/~smdemar/rocketdrag.html
What's left of Jet Stream 500 Specification is here and here.
The writer does incorporate Reynolds numbers.
or Mark's Mechanical Engineer's Handbook.
You just compute your Reynold's number, look where it lies on the xaxis, go straight
up and see where it crosses, move over to the left axis and read CD.
Simple, eh?
You could encode this by looking at various sections and put best fit
straight lines, 2nd or 3rd or 4th order curves through the data points.
Your code would have to use something like in FORTRAN the CASE or
IF THEN ELSE constructs. Ahhh, IF and logicals are in Excel.
I am beginning to believe you should stay in the incompressible
flow regime for now. Get all the bugs worked out and progress from
there.
You ask a lot of questions. I don't know if I can answer them all.
I haven't had time to look over this link.
http://www.altaccel.com/arla/arlaram.htm
But I did look over this one:
http://web.syr.edu/~smdemar/rocketdrag.html
What's left of Jet Stream 500 Specification is here and here.
The writer does incorporate Reynolds numbers.
Now I ask you, Dave, what are the Mach numbers for these speeds?web.syr.edu/~smdemar/rocketdrag.html wrote: Each model was tested at three airspeeds: 80, 100, and 120 km/hr.
The plot is experimental data. This can be found in a variety of textbooks: Kent'sDave wrote: ..... Now, what to do with those Reynolds numbers? ...
That graph from the bicycle website shows the equation for Cd (the same drag
equation I was using, just rearranged) and also makes separate mention of the
Reynolds number on that graph, but the Reynolds number isn't found in the drag
equation. If you can point me towards a drag equation (or the pieces of one, or
whatever) that bridges this gap that would be great.
or Mark's Mechanical Engineer's Handbook.
You just compute your Reynold's number, look where it lies on the xaxis, go straight
up and see where it crosses, move over to the left axis and read CD.
Simple, eh?
You could encode this by looking at various sections and put best fit
straight lines, 2nd or 3rd or 4th order curves through the data points.
Your code would have to use something like in FORTRAN the CASE or
IF THEN ELSE constructs. Ahhh, IF and logicals are in Excel.
I am beginning to believe you should stay in the incompressible
flow regime for now. Get all the bugs worked out and progress from
there.

 Posts: 12
 Joined: Sat Nov 24, 2007 3:14 am
 Antipspambot question: 0
 Location: Audubon, NJ, USA
 Contact:
Re: drag
Hi WebPilot, thanks for the comments! Let's see.....
>Each model was tested at three airspeeds: 80, 100, and 120 km/hr.
>
>Now I ask you, Dave, what are the Mach numbers for these speeds?
I ran my program against that same data set and checked the Mach numbers against the calculator from NASA's website below, taking altitude and speed into account. The Mach numbers it calculated match those produced by the NASA calculator to all available decimal places:
http://www.grc.nasa.gov/WWW/K12/airplane/mach.html
Here are some data points, including speed, altitude, Mach, and Reynolds numbers from my sample data set. Note that the vehicle passes each target speed at least twice, once during the motor boost and again at apogee when it slows down. I'll just show data for the boost phase:
80 km/h = 22.22222 m/s. Closest data point during boost: speed 22.2112 m/s, altitude 2.251 m, Mach 0.065, Re 48695.
100 km/h = 27.77777 m/s. Closest data point during boost: speed 27.715 m/s, altitude 3.48 m, M 0.081, Re 60761.
120 km/h = 33.3333 m/s. Closest data point during boost: speed 33.395 m/s, altitude 5.047 m, M 0.0981, Re 73210.
Note that 120 km/h is only about a tenth of the top speed of the vehicle in this data. At its fastest, the speed is 302.36 m/s, altitude is 458.9 m, M 0.893, and Re 655740. (This data isn't for a ramjet though, it's simulation data for my successful Level 3 rocket flight from the beginning of the year. The real vehicle itself didn't go quite as fast or high as predicted. Hopefully I can fly my first ramjet mockup soon.)
>You just compute your Reynold's number, look where it lies on the xaxis, go straight
>up and see where it crosses, move over to the left axis and read CD.
>Simple, eh?
Hang on, I'm not sure I understand. Are you just talking about looking this up on a graph from a textbook or other similar source such as figure 2 on the bicycle website you linked to earlier? That wouldn't quite work because the curve changes based on the geometry, and the reference curves given are for cylinders and spheres, not rockets or ramjets. Maybe if I had a graph with more reference curves (preferably resembling rockets) I could at least get a ballpark idea... but part of the reason for this whole exercise is that I don't yet trust rocket drag numbers for a ramjet.
>Your code would have to use something like in FORTRAN the CASE or
>IF THEN ELSE constructs. Ahhh, IF and logicals are in Excel.
I'm actually doing all this work in Java, I'm just using Excel for visualization and stuff right now (and for my separate vehicle simulator, until I get a chance to port that over to Java). I'd have killed myself by now if I was trying to do some of this stuff in Excel.
>I am beginning to believe you should stay in the incompressible
>flow regime for now. Get all the bugs worked out and progress from
>there.
Maybe so... It would be nice if this could be a good rigorous general tool that the rocket/jet community could utilize... I have to remember though that at the end of the day, I think this will give me enough data to get started. I still haven't tracked down why my numbers are jittering around, but for now I can just apply a little smoothing and not lose sleep over it.
I think I am at a point where, though my program isn't a polished jewel, I can get started on a ramjet mockup. The next big launch is January 12th and 13th down in Maryland with MDRA. Maybe I can be ready for that. In the meantime, if you (WebPilot) or anybody else has any suggestions or features they'd like added to my program, if it's not too difficult I'd be glad to try and put it in for when I release it.
As always, thanks for the comments and help! This is all fairly new to me and the pointers are great.
Dave
>Each model was tested at three airspeeds: 80, 100, and 120 km/hr.
>
>Now I ask you, Dave, what are the Mach numbers for these speeds?
I ran my program against that same data set and checked the Mach numbers against the calculator from NASA's website below, taking altitude and speed into account. The Mach numbers it calculated match those produced by the NASA calculator to all available decimal places:
http://www.grc.nasa.gov/WWW/K12/airplane/mach.html
Here are some data points, including speed, altitude, Mach, and Reynolds numbers from my sample data set. Note that the vehicle passes each target speed at least twice, once during the motor boost and again at apogee when it slows down. I'll just show data for the boost phase:
80 km/h = 22.22222 m/s. Closest data point during boost: speed 22.2112 m/s, altitude 2.251 m, Mach 0.065, Re 48695.
100 km/h = 27.77777 m/s. Closest data point during boost: speed 27.715 m/s, altitude 3.48 m, M 0.081, Re 60761.
120 km/h = 33.3333 m/s. Closest data point during boost: speed 33.395 m/s, altitude 5.047 m, M 0.0981, Re 73210.
Note that 120 km/h is only about a tenth of the top speed of the vehicle in this data. At its fastest, the speed is 302.36 m/s, altitude is 458.9 m, M 0.893, and Re 655740. (This data isn't for a ramjet though, it's simulation data for my successful Level 3 rocket flight from the beginning of the year. The real vehicle itself didn't go quite as fast or high as predicted. Hopefully I can fly my first ramjet mockup soon.)
>You just compute your Reynold's number, look where it lies on the xaxis, go straight
>up and see where it crosses, move over to the left axis and read CD.
>Simple, eh?
Hang on, I'm not sure I understand. Are you just talking about looking this up on a graph from a textbook or other similar source such as figure 2 on the bicycle website you linked to earlier? That wouldn't quite work because the curve changes based on the geometry, and the reference curves given are for cylinders and spheres, not rockets or ramjets. Maybe if I had a graph with more reference curves (preferably resembling rockets) I could at least get a ballpark idea... but part of the reason for this whole exercise is that I don't yet trust rocket drag numbers for a ramjet.
>Your code would have to use something like in FORTRAN the CASE or
>IF THEN ELSE constructs. Ahhh, IF and logicals are in Excel.
I'm actually doing all this work in Java, I'm just using Excel for visualization and stuff right now (and for my separate vehicle simulator, until I get a chance to port that over to Java). I'd have killed myself by now if I was trying to do some of this stuff in Excel.
>I am beginning to believe you should stay in the incompressible
>flow regime for now. Get all the bugs worked out and progress from
>there.
Maybe so... It would be nice if this could be a good rigorous general tool that the rocket/jet community could utilize... I have to remember though that at the end of the day, I think this will give me enough data to get started. I still haven't tracked down why my numbers are jittering around, but for now I can just apply a little smoothing and not lose sleep over it.
I think I am at a point where, though my program isn't a polished jewel, I can get started on a ramjet mockup. The next big launch is January 12th and 13th down in Maryland with MDRA. Maybe I can be ready for that. In the meantime, if you (WebPilot) or anybody else has any suggestions or features they'd like added to my program, if it's not too difficult I'd be glad to try and put it in for when I release it.
As always, thanks for the comments and help! This is all fairly new to me and the pointers are great.
Dave

 Posts: 3716
 Joined: Tue Dec 07, 2004 6:51 pm
 Antipspambot question: 0
 Location: 41d 1' N 80d 22' W
Re: drag
My point about the Mach numbers for 80, 100 and 120 km/hr was
that the website's data was still for incompressible flow.
least know what flow regime the data is good for.
Good luck with your efforts!
that the website's data was still for incompressible flow.
That's a given. It should be out there somewhere. Now you'll atMaybe if I had a graph with more reference curves (preferably
resembling rockets) I could at least get a ballpark idea.
least know what flow regime the data is good for.
Good luck with your efforts!
Cd for a ramjet
This spring (once things thaw out a bit) I'd be willing to launch a rocket with and without a ramjet attached to determine the true Cd of the ramjet. I have an ARTS2 (as well as a few other recording alts) which can calculate the Cd at each sampling (200Hz) Once we have Cd for the rocket at various speeds with and without, the difference is the Cd of the ramjet. I can also use some of the 38mm and 54mm Warp9 motors to go beyond mach1 to get supersonic Cd. Naturally, the ramjet would just be going along for the ride and would be unfueled.
If you can design it (both the rocket in RockSim and the ramjet) then I can build it although I'd want to keep it smaller (I'm only a NAR L2, so no M motors or above) It'd give you some real data to track back to your program.
Aaron
If you can design it (both the rocket in RockSim and the ramjet) then I can build it although I'd want to keep it smaller (I'm only a NAR L2, so no M motors or above) It'd give you some real data to track back to your program.
Aaron

 Posts: 12
 Joined: Sat Nov 24, 2007 3:14 am
 Antipspambot question: 0
 Location: Audubon, NJ, USA
 Contact:
Re: drag
Hey Aaron, thanks for the note. I actually didn't know the ARTS2 came with that software. That's very cool  frankly if I had known that I probably wouldn't have bothered with writing my own software. Granted, it's nice to have the code so I can make it do anything I want (and it's been a good learning experience for me), but it's so much easier to spend the $200 and buy the ARTS. (Unfortunately now's not a good time to be dropping $200 on something I don't need. ) I'm gonna continue cranking on this software for a while, also refining my ramjet performance estimation tool in parallel, but it's nice to know the ARTS is a fallback plan or something to verify against. (So far it's looking ok but it's also showing Decker designs as probably not producing enough thrust to overcome drag and their own weight. Hopefully real data will show that to be wrong.)
Turns out I'm not going to have anything ready to launch by this weekend, but I am at least hoping to show up and see if I can convince people to give me their flight data to run through my program. Next month I'm hoping to have some custom propellant to static test and characterize, and if I'm really lucky maybe I'll be able to drag test a ramjet.
>If you can design it (both the rocket in RockSim and the ramjet) then I
>can build it although I'd want to keep it smaller (I'm only a NAR L2, so no
>M motors or above) It'd give you some real data to track back to your
>program.
I may end up taking you up on that... I'm hoping to have made more headway and possibly even conducted some drag tests by that time. We'll see.
Thanks for the info!
Dave
Turns out I'm not going to have anything ready to launch by this weekend, but I am at least hoping to show up and see if I can convince people to give me their flight data to run through my program. Next month I'm hoping to have some custom propellant to static test and characterize, and if I'm really lucky maybe I'll be able to drag test a ramjet.
>If you can design it (both the rocket in RockSim and the ramjet) then I
>can build it although I'd want to keep it smaller (I'm only a NAR L2, so no
>M motors or above) It'd give you some real data to track back to your
>program.
I may end up taking you up on that... I'm hoping to have made more headway and possibly even conducted some drag tests by that time. We'll see.
Thanks for the info!
Dave