Computational Fluid Dynamics (CFD) =advanced=

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

illini

Well-Known Member
Joined
Oct 9, 2003
Messages
1,280
Reaction score
0
The “flat plate” thread was starting to degenerate into a discussion of CFD tools which I thought might have merit as a thread in its own right. In what follows, I'm going to give a short description of the equations of motion, what they capture, then describe ways to capture their effects with CFD.

Let's start with the fundamental equations of fluid dynamics, known as the Navier-Stokes equations. The Navier-Stokes equations are a set of coupled, non-linear partial differential equations that are suitable for describing time-varying, compressible (with shocks), viscous flows with turbulence. However, there is no general solution to these equations, meaning that theorists have to apply further limiting assumptions in order to arrive at solutions, or that they must be solved numerically, in which case the numerical method itself introduces additional assumptions. In fact, the Navier-Stokes equations themselves are the result of several assumptions.

To solve the full Navier-Stokes equations numerically typically requires a finite difference or finite volume method which breaks up the space around or inside the body of interest into little cells, then solves a linearized, algebraic approximation of those equations in each cell. The linearized, algebraic approximation approaches the true equations in the limit as the cell size and the time step size go to zero. However, since no computer can handle infinitely dense grids and infinitesimally small time steps we must accept the error inherent in less dense grids and larger time steps (this too is limited by numerical stability constraints) in exchange for timely solutions. As a CFD professor of mine was fond of saying, “you can't catch a small fish with a large net,” meaning that a large grid inevitably means loss of detail and, therefore, a sacrifice in accuracy. Furthermore, the numerical methods themselves have a nasty tendency to distort solutions by adding in their own artificial viscosity and waves. Sometimes these artifacts of the numerical algorithms are necessary for numerical stability. But in any case, they distort the solution.

The full Navier-Stokes equations solved numerically on a sufficiently dense grid to catch even the smallest turbulent eddy (the smallest fish) can simulate turbulence directly. Since this is highly computationally intensive, resolving some of the largest eddies while sacrificing some of the smallest eddies and modeling their effects with mathematically artificial turbulence models leads to a large eddy simulation. However these are still computationally intensive. The movie at this url: https://mysite.verizon.net/vze3qt6z/Thesis.qt is from my Ph.D. thesis and required 100 hours of Cray time.

Since resolving even large turbulent eddies is computationally expensive, most Navier-Stokes solvers model the effects of turbulence using what is known as the Eddy Viscosity Hypothesis. The Eddy Viscosity Hypothesis states that turbulence acts like viscosity on steroids, therefore we can account for its effects by jacking up the viscosity coefficient where appropriate. A variety of turbulence models exist (such as k-epsilon) for computing the eddy viscosity. But these, of course, are very gross approximations of what really goes on with turbulent flows. So, bottom line: your typical Navier-Stokes solver has replaced actual turbulence with an eddy viscosity, can only resolve whatever the grid and time step allow it to resolve, linearizes the equations locally, and introduces artificialities. As long as you understand how to balance all these factors and the impact of the assumptions, you can use such a flow solver with great effect.

Viscosity is not terribly important for many problems so the viscosity terms are often dropped from the Navier-Stokes equations, giving us what is known as the Euler equations. Dropping viscosity greatly speeds up solutions, while still preserving the ability to capture shocks. By dropping viscosity, we lose boundary layer profiles, turbulence (but not necessarily vortex shedding), and the shape of shocks (amongst other things), but retain compressibility (necessary for high speed and supersonic flight) and the ability to capture form drag. The numerical methods will be similar to the Navier-Stokes flow solvers, and have the same limitations.

If we can also drop compressibility we can further reduce the equations (to be clear, we can drop compressibility while retaining viscosity if we like). Fluid dynamicists use Mach 0.3 as a rule of thumb for determining whether compressibility is important. If it isn't, the equations become simpler. If we can say that a fluid is both incompressible and inviscid, then we call it an ideal fluid (something that doesn't exist...this is an approximation). Numerical methods will be similar to above: spatial grids with time stepping flow solvers that linearize the equations and introduce their own numerical artifacts.

If we have an ideal fluid that we can assume to be irrotational, then we can formulate the potential flow equations and use a panel method to solve. We can make a panel method approximate compressibility effects through linear extensions to the equations. This is what AeroCFD does. Panel methods don't require grids, but rather distribute little vortex panels along the surface of the object of interest. This is much simpler and straightforward than gridded CFD methods, but still very powerful.

Believe it or not, this is a very brief synopsis of the levels of CFD that exist out there. Somebody somewhere is bound to step in and tell me what I left out and they'll be absolutely correct. Several of my old professors would probably crucify me for some of the corners I cut in this description. However, it is not my intent to be exhaustive. Also, believe it or not, my intent is not to pick on AeroCFD and point out that it lives on the lowest rung of the CFD ladder. Not even close. Rather, my intent is for everybody to understand the number of assumptions, limitations, and – yes – capabilities inherent in CFD software. Tools like AeroCFD can be extremely useful, but will be even moreso when we understand what they can and cannot do.
 
I'm sure this is great stuff...but I'll have to come back to it later ;)
 
Been shopping all day...brain swollen....wallet empty...need sleep...
 
Is there any CFD software that is PC compatible. I found a couple that are freebies, but all require UNIX, and then the few I looked at required a sepatrate rendering engine.

I downloaded one, dusted off my SGI Indigo Iris, found I had the wrong version of UNIX, took a look at another UNUIX machine (HP340) found that $40K worth of workstations are now outperformed by my PDA, got disgusted and went back to the bench.

I'd like to toy with this a bit, any suggestions?

A
 
Originally posted by Hospital_Rocket
Is there any CFD software that is PC compatible. I found a couple that are freebies, but all require UNIX, and then the few I looked at required a sepatrate rendering engine.

I downloaded one, dusted off my SGI Indigo Iris, found I had the wrong version of UNIX, took a look at another UNUIX machine (HP340) found that $40K worth of workstations are now outperformed by my PDA, got disgusted and went back to the bench.

I'd like to toy with this a bit, any suggestions?

A

A UMSDOS (Unix under MS-DOS) Linux? Lives on and boots from a regular WinX drive, doesn't require diddling with dual-boot, removes cleanly if there's a problem. Slackware used to have that option, as did muLinux.
 
Teflon's got it. The Aerorocket stuff looks pretty good, and it looks like he's really gone out of his way to make it mainstream and accessible to the average modeler (not that *you're* an average modeler...oh...what the heck am I apologizing for...you know what I mean). Start with AeroCFD, but I do like what he's done with the other stuff as well. Some of the other *free* packages you'll find out there - especially those designed to run on Linux or Unix - are likely to be industrial or academic strength, meaning that you'll only get frustrated trying to use them. In my opinion, the greatest value of packages like AeroCFD for modelers is education...actually getting to visualize a flow field. Those industrial strength packages aren't going to educate you much.

As for me... If I ever get any free time I might have to start writing some flow solvers again. For fun this time, not for pay.
 
A word of caution with any CFD or other computer simulation package.

Computer simulation programs solve complex differential equations very precisely for you, but they can not think for you. You have to have a basic understanding of the phenomonology that you are trying to visualize.

As with RockSim or any other computer simulation program, the results that you obtain from a simulation are only as good as the data you input into the model. If the data you enter is accurate, you will get a precise and accurate simulation of fluid flow with a good CFD code. If you put in bad data, you will get a very precise, but a totally inaccurate simulation. That's where knowledge and experience come into the picture.

On more than one occasion, I have had people ask me why my experimental data was so bad. When asked why they thought the experimental data was bad, they responded that the model said you should get this answer and it's not what you got. My next question is what data and boundary conditions did you put into the simulation. After they shrug, and without going into further detail, I simply give them the correct input data and boundary conditions and ask them to rerun the code. They come back and are totally astounded how good my data has become.

Bob Krech
 
Absolutely right, and that is the warning I'm trying to give.

HOWEVER, I will also offer a counterexample of a problem my former company ran into several years ago. Test after test, motor firing after motor firing could not produce the data needed to solve the problem...provided zero insight whatsoever. A quick and dirty CFD model, quasi-1D equations no less, nailed it and provided all the insight we needed (of course, that model was produced and run by someone with experience...me). In fact, it produced the only results that matched the flight data we had recorded. In the end, the results were uniformly rejected by upper management...would have put the company and their customer in a bad light.
 
Originally posted by illini
...In the end, the results were uniformly rejected by upper management...would have put the company and their customer in a bad light.

That's what management is for, isn't it: to make the company look good?

(Not an advanced topic, I'll be the first to admit.)
 
Finally read this thread. One step more detail that I was aware of...and enough for my purposes. Thanks for taking time to prepare this...now on to the movie....got popcorn?
 
Don't get your hopes up on that movie! One of the reasons I posted it is for people to note in their own minds (without my having to say it...which I now just did) how ridiculous it is to use 100 hours of Cray time for 10 seconds of "flow". :eek: Hey...it got me the degree, alright?
 
Agree with you on the quick and dirty stuff.

I always do quick zero order, and sometimes first order estimates on what I expect to see before I do an experiment.

If you don't see what you expect to see, then you use any means possible to uderstand what's going on. CFD is a wonderful tool in the hands of an experienced user. Saves a lot of expensive experimental work.

Space Ship One was designed by CDF rather than the conventional wind tunnel methods. Much cheaper and much faster. When anomolies were observed in flight, the CFD input parameters were varied to see if the differences were due to the model or the vehicle. Modifications to the vehicle and the model were effieicntly made and they went on to the next flight. It doesn't get much better than that for close-coupling vehickledesign to flight data and CFD modeling.

Bob Krech
 
And yet, they still had to make a model of the thing and toss it from the control tower to test glide properties! Beautiful...
 
Originally posted by illini
In my opinion, the greatest value of packages like AeroCFD for modelers is education...actually getting to visualize a flow field. Those industrial strength packages aren't going to educate you much.

I received an early beta version of AeroCFD from Apogee, before the product was going to be released to the public. Apogee was letting people look at it and give their impressions. I'm a software engineer, so I'm pretty critical of user interfaces. It had a clear and understandable user interface. I was very ignorant as to what the results meant, which was my own fault, but the application ran very well. It was educational. For that, alone, it is valuable.

The only immediate practical application I could see was in choosing a location for your static ports for your altimeter bay. IIRC, you could increase the airflow velocity and observe areas of low and high pressure flow. I would think that it would be good to place your static ports in a part of the airframe that didn't have high pressure flow area move over it as the velocity increased or decreased.

Again, it was personal ignorance that made it hard for me to understand the practical utility of the application. I'm sure there is more that you could do with it.

urbanek
 
So would it be more useful to run RocSim, or AeroCFD and wRASP?
If performance is driven by weight, thrust, and drag coefficient then it would make sense to have the most precise Cd possible. Find that out using CFD, then load the results into wRASP to run your sim. Seems to me you wouldn't really need RocSim if AeroCFD allows you to build a more accurate design.
Are there other factors I'm missing?
 
Originally posted by Chilly
So would it be more useful to run RocSim, or AeroCFD and wRASP?

Useful is in the eye of the beholder. ;)

RockSim is, of course, much more than an altitude prediction program. It does many things, but altitude prediction is certainly one of its leading areas for criticism and argument. Some say its very accurate if only you input precise parameters. Others claim otherwise. I have my own opinions (which are, of course, the correct ones ;)), but the real question to me is, just how accurate do you need your altitude prediction to be? Most simulations don't do absolute predictions very well. Predicting relative trends is usually as much as you can hope for (I'm in the middle of writing a techical paper for a conference this summer that, in part, makes the case that a low-fidelity simulation - at least for my application - can provide remarkable insights...better than highly detailed models that seek - and fall short of - absolute accuracy.). So...how badly do you want that extra ounce of accuracy, and what is it going to do for you? That being said, from what I've seen of the technical specs of AeroCFD it is definitely a step up from the RockSim Cd estimator. If you really want that extra accuracy OR you just want to learn more about what a flowfield looks like (within the limits of AeroCFD's assumptions, that is), then AeroCFD should be a nice counterpart to either RockSim or wRASP.
 
Originally posted by Chilly
So would it be more useful to run RocSim, or AeroCFD and wRASP?
If performance is driven by weight, thrust, and drag coefficient then it would make sense to have the most precise Cd possible. Find that out using CFD, then load the results into wRASP to run your sim. Seems to me you wouldn't really need RocSim if AeroCFD allows you to build a more accurate design.
Are there other factors I'm missing?

Does wRASP allow you to import your own Cd vs. velocity curve (say, from AeroCFD)? I seem to recall that this function wasn't enabled the last time I looked at wRASP. If not, then you are limited to a constant Cd. This isn't necessarily a bad thing. See my back-tracking post at the end of this thread:

https://www.rocketryforum.com/showthread.php?threadid=13352

RockSim does offer Cd vs. velocity based on the venerable Estes TR-11 and Hoerner. You can also fix the Cd to a constant value and get a result nearly identical to wRASP.

The advantage of RockSim over AeroCFD + wRASP is:

1. 2d flights with wind and other weather variables

2. A wealth of data to analyze (if you are a numbers dork, like me.)

3. CAD and parts databases (probably the most important feature for 90% of RockSim users.)

Ken
 
Originally posted by Chilly
So would it be more useful to run RocSim, or AeroCFD and wRASP?
If performance is driven by weight, thrust, and drag coefficient then it would make sense to have the most precise Cd possible. Find that out using CFD, then load the results into wRASP to run your sim. Seems to me you wouldn't really need RocSim if AeroCFD allows you to build a more accurate design.
Are there other factors I'm missing?

Chilly

You are confusing the issue. wRASP, RocSim and AeroCD are 3 different programs and each one does different things.

1.) wRASP (Free) is a simple altitude simulation program. Nothing more. It's not a rocket design program. You give it an average Cd, Diameter, and weight; throw in a motor; and you get an altitude prediction. It's a free, easy to use plain vanilla altitude prediction program you can download into your computer.

https://www.wrasp.com/wrasp.html

Mark Sullivan's altitude predictor is a similar free on-line package.

https://webalt.markworld.com/webalt.html

2.) RocSim ($95) is a CAD package for designing rockets that has an extensive parts database with an altitude prediction subroutine. It uses the exact same equations of motion that the simple altitude prediction programs use, but it calculates the Cd as a function of Mach number based on a series of relatively simple accepted empirical equations which in theory will give a more accurate trajectory prediction. Be aware that the prediction is only as good as the data you input to the program. If you don't model your rocket exactly, you will not get an accurate flight simulation.

https://www.apogeerockets.com/rocksim.asp

3.) AeroCFD ($65) is a subsonic, (M < 0.8) CFD package that calculates Cd vs Mach Number by solving a set of differential equations. It is theoretically more accurate than the empirical equations used in RocSim however again it can only be as good as your data input, and from what I gather from the description on the website, will not calculate transonic or supersonic Cds. You really don't need to see the flow field around the rocket to predict the altitude (but it is cool).

https://www.aerorocket.com/aerocfd.html

Other alternatives are

4.) VisualCFD ($180) appears to be a better package for HPR that go transonic or supersonic. It contains the guts of AeroCFD for subsonic flow, and also handles transonic and supersonic flow.

https://www.aerorocket.com/VisualCFD/Instructions.html

5.) AeroDRAG & Flight Simulation ($30) actually appears to be the most practical altitude prediction package of the lot. It calculates Cd from 0 < M < 20. It simulates the atmosphere to 500 kft. It calculates the subsonic Cd of tube-fin and ring-fin model rockets. It is not a rocket CAD package but it is a rather sophisticated altitude prection package, and it does that for a lot less than either AeroCFD or RocSim.

https://www.aerorocket.com/aerodrag.html

and to go where no others have gone before

6.) If you really have to know where your rocket is going to go you need SPLASH ($130). Splash is a wind-weighted 6 degree-of-freedom (6DOF) rocket simulation with statistics-based impact analysis capability. Splash is intended not just for the nominal trajectory analysis that most simulations are, but also for splash pattern generation consistent with FAA/OST requirements. This means that Splash can provide the data used to determine not just a nominal impact point but an impact zone complete with statistics to back up the likelihood of a vehicle impact in any given region. Same type of program the big boys use, and no other simulation package available at a reasonable price offers this capability.

https://www.apogeerockets.com/splash.asp

https://www.splashpattern.com/

Final Thoughts.

For modroc wRASP is really all you need to predict altitude. RocSim is a design tool, and if you do a lot of scratch-building, it's really useful. So are any other rocket CAD packages with a database of parts.

For L1 and L2, the addition of the AeroDRAG & Flight Simulation software to the above list seems like a good idea. At $30 it's a steal.

If you're flying L3 or larger, get all of them. They're cheap compared with the cost of the rocket, so don't use the excuse that you can't afford them.

Bob Krech
 
Originally posted by illini
the real question to me is, just how accurate do you need your altitude prediction to be? Most simulations don't do absolute predictions very well.

Even more to the point, most simulations require some experience to be applied to get good results. You need experience to check the results you're getting, especially when you enter non-standard parameters. I always get a kick out of people who enter spool rockets or flying saucers into RockSim and expect it to spit out usable results. It won't.

Remember that the motor's thrust curve can vary quite a bit, as can the angle that the rocket flies, the atmospheric conditions, etc. Hit a big wind shear, and make the fins work hard (lots of induced drag) and suddenly you can change your final altitude by quite a bit.

Example: We have a contest at Hellfire every year: closest to 15,000'. A guy at the last Hellfire launch flew the same rocket, with the same motor type, from the same launch site, but the flights were separated by about 1 year. Different launch conditions, different launch pad, different atmospheric conditions and, of course, a different motor of the same type. One year the rocket flew just over 15,000'. The next year, the rocket flew around 11,000'.

That's not a simulations, that's reality. So you have to ask yourself, what do you actually need the simulation to do for you? What job is it going to do?

I had a friend who used to stress out over whether the predicted deployment speed was too high. He'd fiddle and fuss and worry over this and I could never convince him that the number he was worrying about was just a guess. I tried to tell him the difference between an:
EWAG: Educated Wild *** Guess (someone with experience, guessing the outcome),
WAG: Wild *** Guess (just anyone guessing the outcome),
CGWAG: Computer Generated Wild *** Guess (Something without any native intelligence churning out a number)

Of the three, the CGWAG is the worst. Believe me, I write software for a living. Violate any of the input parameter assumptions, and you can get all sorts of goofy numbers. Unfortunately, you rarely know what the input assumptions are.

urbanek
 
Beautifully said. Thanks! I've made similar points in other threads before, and didn't want to be the one to hammer on them yet again!
 
Atmoshperic modeling is what I was wondering about, and probably should've been more specific. I didn't know the difference between wRASP and RocSim's methods. Also didn't know AeroCFD will only do subsonic modeling. For my purposes & budget, RocSim is all I need.

Believe me, I know of what you speak with computer predictions vs. real-time conditions. This discussion reminds me a lot of computerized flight planning...it's unbelievable how many complaints we get from our crews about things like winds & temps aloft. Both have a profound effect on fuel consumption but the forecast models are only updated twice a day. So if the models are crap, we're still stuck with them for twelve hours. And we can't know they're crap until someone gets up there.

As we like to say, "that's why it's called a flight *plan*". I've been able to outsmart the computer several times but only because of prior experience.
 
Originally posted by Chilly

Believe me, I know of what you speak with computer predictions vs. real-time conditions. This discussion reminds me a lot of computerized flight planning...it's unbelievable how many complaints we get from our crews about things like winds & temps aloft. Both have a profound effect on fuel consumption but the forecast models are only updated twice a day. So if the models are crap, we're still stuck with them for twelve hours. And we can't know they're crap until someone gets up there.

As we like to say, "that's why it's called a flight *plan*". I've been able to outsmart the computer several times but only because of prior experience.

There are ways to automatically build plans that are tolerant of variation (i.e., "robustness"), but that's off topic and I think we discussed that before!
 
Originally posted by Chilly
Atmoshperic modeling is what I was wondering about, and probably should've been more specific. I didn't know the difference between wRASP and RocSim's methods. Also didn't know AeroCFD will only do subsonic modeling. For my purposes & budget, RocSim is all I need.

RockSim uses the 1977 Standard Atmosphere (I think). As for wRASP, again I remember having difficulty with the atmospheric model options. The software may have been limited to a constant rho.

As for the calculation methods of RockSim and wRASP, they solve the same ODEs with the same numerical schemes for 1D flight. RockSim adds to the complexity of the equations by simulating 2D flight with wind and other wacky weather (thermals, wind shear, variability, etc.)

Can anyone confirm if wRASP allows you to import a Cd curve?

Ken
 
Unfortunately, wRASP does not support importing CD values.
 
Ken

The HELP window of wRASP has answers to your questions.

DIGITRAK is the program incorporated into wRASP that would allow you to import a Cd profile, but this option does not appear to have been incorporated into wRASP V2.1 that I have, and I don't think there is a newer version.

Apparently wRASP uses a standard atmospheric profile (ICAO standard day) to about 36 kft. or you can use a constant density option in DIGITRAK.

David Schultz is acknowledged as a reviewer, so maybe he can give some further comments.

Bob Krech
 
Back
Top