Review of OpenFOAM: free CFD
 

OpenFOAM has been mentioned once or twice in this forum before, but it hasn't been given a fair shake. It is a rather general-purpose open-source numerical solver, with capabilities ranging from chemical reactions (think ICE cumbustion simulation) to 3d wind-tunnel CFD.

I think the short story is that it works and it's free; it's just a much steeper learning curve than commercial CFD packages that have GUI's.

Here is a screen-shot. I ran a tutorial which imported a 3d model of this motorbike and ran a (computationally simplistic - probably inaccurate - in this case) wind-tunnel CFD. Then I opened it in the paraviewer and put in a transverse slice and stream-tracer (a virtual smoke-wand).
http://ecomodder.com/forum/attachmen...1&d=1379864648
That's about all I've been able to do so far.

My goal is to be able to write as simple a tutorial as possible describing running a car and mods through an OpenFOAM virtual wind-tunnel CFD.

Given how far away I am from that goal, and how low a priority this is for me, I hesitate to post now - I may not get there for another 3-12 months - but maybe this will stimulate some interest.

Learning curve, prerequisite, initial thoughts:

1. I guestimate a single study will require in the neighborhood of 2 million floating-point-operations for an automotive scale wind-tunnel, so I'm guessing an Intel I5-3570K clocked at 4.5 GHz, for reference, will take around 4 hours. My laptop with an I5-3210M might be more like 15 hours, as long as the heat doesn't slow it down. However the study I'm basing this on lacked some of the CPU specifics, so consider it a crude guess.
2. Linux required: those not already running Linux need to setup a new partition (google gparted livecd), and install Linux, preferably a supported Ubuntu version such as 12.04 LTS or 13.04. See the OpenFOAM download page: Download OpenFOAM®. I'm a Debian guy, and it wasn't a big deal to build OpenFOAM and the thirdparty package from the source packages on Wheezy, but it was a disaster on Squeeze (the previous release). Actually, I did find a Windows build using Cygwin, but I noticed it was out-of-date. Why bother? In my opinion the Linux hurdle is small compared to the others.
3. The learning curve is quite steep, I'm guessing in the 100-hour neighborhood. Consider OpenFOAM a command-line utility with text-file controls. I need to learn how to a) import a 3d model from STL, b) mesh the model, c) setup appropriate pre-processing and processing, d) analyze results using Paraview.
4. You need a good STL model of your car and a CAD program to create mods in the first place. I'm using Solidworks, which I have access to, but I don't see why Sketchup wouldn't work (or Geomagic Design or FreeCAD). I still haven't found a satisfactory Civic model for free. If you want to buy a model they often run around $75, although one website I know of will net 5 different models for $125, so maybe there's an opportunity to pool for car models at $25 each.
5. Even after all this, CFD will give the best results if you have a reference case that you can compare in detail to the CFD results. I think in principle that if you increase the resolution and computational detail (and simulation time) to some unreasonable quantity then the CFD results should end up being accurate. But in practice, where simulation time is not an infinite resource, there needs to be a real-world reference case to ensure the CFD isn't overly truncated.

OpenFOAM in literature

• I like to read master's theses; I often learn from the background reading as well as the subject matter. This one features a comparison of OpenFOAM to a commercial CFD package - Fluent. OpenFOAM: A tool for predicting automotive relevant flow fields. In summary: OpenFOAM's predictions are realistic, but not as realistic as Fluent in terms of detatchment points, and also OpenFOAM is slower than Fluent. Also, OpenFOAM has a steep learning curve and requires investment of a lot of time to operate it properly.
• Some of the Coventry University 2011 research has been posted on Ecomodder previously; I noticed they used OpenFOAM in some of their CFD studies. Aerodynamic Drag Reduction and its Effects on Electric Vehicles

Cheers,
Chris

I use OpenFOAM daily. I can help people out pretty easily set up a case properly (not just to get pretty pictures).

My linux machine use to look like this:
http://i1291.photobucket.com/albums/...untuScreen.png

What a simple iteration case looks like after solving:
http://i1291.photobucket.com/albums/...caseScreen.png

Simple surface mesh of simplified Scion FRS:
http://i1291.photobucket.com/albums/...rfaceMesh1.png

Close up of mesh generation with snappyHexMesh:
http://i1291.photobucket.com/albums/...rfaceMesh2.png
**Not the best mesh generation provided in that picture...just for representation**

Semi case I worked on:
http://i1291.photobucket.com/albums/...ps957b354a.jpg

FRS case:
http://i1291.photobucket.com/albums/...ps0adfcfc2.jpg

Top Fuel Dragster:
http://i1291.photobucket.com/albums/...ps2e43ff64.jpg

I can help start a tutorial if needed also. I have been using OpenFOAM for about 2 years and using it for aero consulting for the last year.

Sweet, some expertise!

Do you have enough posts to attach a sample snappyHexMeshDict (ecomodder accepts zip files up to 97.7kb, maybe I should ask for all your dictionary files for one case, if possible)? [PM me if needed; we can do a dropbox or setup an FTP folder on my server or something, if that helps.]

I think I can attach files now. The snappyHexMeshDict is only around 3kB so I bet I can attach them all. I think what I will do is set up a specific case for my Golf I am going to start running cfd on. I will share my files for that for everybody to see and then it will also have the ability to see how I analyze the data. I cannot share the exact files on the cases I consulted on. I will get working on that this week between other projects :cool:

Let me know if you run into any trouble before then on specific problems :thumbup:

Great examples. Just to add that there are a couple of native Windows port of openFoam available - try to avoid cygwin ports as computational time really increases.

Free one at: https://code.google.com/p/bluecfd-singlecore/ - it does not support multiple core though.

My challenge is that the hardware I have available to run Linux is pretty old.

My other challenge is getting my holey and rough SketchUp model into a file format that OpenFOAM can import.

I am not sure I can help there....

openFoam uses STL and obj format. You can export from SketchUp into STL using stl4su STL for Sketchup - Browse Files at SourceForge.net. To install you need to download the stl4su.rb file and copy it in the plugins directory of the SketchUp installation. Then start SketchUp and the plugin should have added a "Export to STL" entry to the Tool menu (at least it does so under SketchUp 8).

I can't really help with the rough part of the SketchUp model, but for the holey part there are a number of things you can do:

- Leave it holey and cross your finger (it works sometime);
- Fix it using the openFoam utilities;
- [my preference] Fix it using Netfabb Studio Basic (free) netfabb Basic
- Fix it using another mesh tool such as MeshLab.

I was wondering if you may be aware of Best Practice Guide/Guidelines that are tailored for automotive aerodynamic. I am aware of a few BPG (Ercoftact, Marine, etc) but none that is automotive specific.

Can you be more specific? If so I should be able to send you in the right direction or just tell you myself if I know.

I was wondering if there was a single document covering issues such as:

- geometry: What simplifications are "acceptable"?
- size of the computational domain, incl blockage ratio, number of length before and after;
- mesh such as first layer size, number of layer in boundary layer, mesh resolution in near and far field;
- boundary conditions;
- physical, incl turbulence models, and numerical models;
- typical validation models;
- and ideally a discussion on limitations.

If you have access to the Ercoftac BPG, I would be looking for something similar but applied to the automotive industry.

1. geometry: What simplifications are "acceptable"?
This is a tough one to answer because it just depends. It depends what the end goal of the project is and what kind of accuracy you are looking for. Example: You could have a much more simplified model if you are testing basic front end designs, than say if you are testing underbody flow for engine cooling.
***My usual simplifications: simplified underbody (not just flat however), simplified suspension and brakes, simplified engine (if I even have an engine(ony when using porous flow through a radiator)), and I am sure I am forgetting a few others.

2. size of the computational domain, incl blockage ratio, number of length before and after
The size I usually use is 5x length in front of car, 15-25x length behind, and 2-5x length on sides depending on the project. I do not know if this is industry standard or not, just what I picked up from one of my professors. I never thought of calculating blockage ratio however since I have only used that when looking at a windtunnel. Computational domain depends really and everybody will give you something different. I think you need at least 5 million for normal automotive, but more like 25 million for a complicated open wheel car.

3. mesh such as first layer size, number of layer in boundary layer, mesh resolution in near and far field
I use yplus for this. I just keep a yplus that is acceptable for the turbalance model I am using.

4. boundary conditions
The normal for this I guess. I do rotating wall velocity for the wheels. The walls are set to the internal velocity field so wall velocity to not see boundary layer growth.

5. physical, incl turbulence models, and numerical models
For turbulance models, I usually use k-omega SST because I like how it correlates pretty well but takes longer to converge than say a k-epsilon. I would say that the three most common for steady state analysis is k-epsilon, k-omega, and k-omega sst. LES and DES are becomming more popular however with computing power increased. I will occasionally do a transient analysis, but most cases I can get away with steady state. I normally use a steady state incompressible solver except if I need transient or compressible (dragster).

6. typical validation models
The ahmed model is the most common and what I have used. I have also been able to validate a case using a windtunnel also.

7. and ideally a discussion on limitations
Really just depends on the knowlege of the engineer, time, and computing power. Plus a little common sense

I hope that is clear. I could go further on some things but that is the jist. Plus I have a case to setup :D

Thanks a lot for the info. I seem to understand that your best practice are derived from experience, rather than taken from literature - although most looks pretty much common sense. Is this correct?

A quick question on the Ahmed body. My understanding is that the measurements are focused on the pressure in the rear body (particularly on flow field vs rear angle and flow detachment). How are you fining correlation between k-omega SST and experiment? I was under the impression that the "standard" was linear k-epsilon with non-equilibrium wall function. What is your experience?

More or less yes. But some of the info from working with my professor was from literature also. I used a both approaches as there is no set in stone best way to set up since all cases are different.

Yes the Ahmed body is to study the separation of flow on the "hatch"/slant of the bluff body. It is also good way to study the wake. You are correct in saying that the the k-epsilon is considered standard and it also correlates better to the windtunnel data from the ahmed study. In most cases I ran with different turbulance models, k-epsilon showed a slightly higher drag and lift value. This correlated closer to the actual measured drag and lift.

After that, you might be wondering then why I don't use k-epsilon. The reason is from talking to more experience people than myself about its correlation to real world motorsports cases. I discussed this in detail with one. Basically they noticed that the k-omega sst model worked better in cases with high separation. Since most actual cars and racecars have a good amount of separation of flow, it usually is gets better results. ***Other people will disagree however since I know many who still use k-epsilon*** Also remember, it is just a mathematical model to represent the chaos that is turbulence.

Thanks again. If you don't mind me asking:

- Are the pictures you posted earlier generated with EnSight? They did not look like the typical ParaView pictures associated with openFoam simulations;

- What hardware and simulation turn-around time do you use of a typical simulation? Is it in-house hardware?

Thanks.

Yes. I had access to EnSight for a while. I love it personally and I am looking at picking it up soon. It has more options and math available than ParaView. I am currently using ParaView however since I no longer have access to EnSight until we decide to purchase it :(

I use a small cluster of workstations obviously running linux. Depending on the size and convergence anywhere from 18-48 hours. It is in-house, but I did try amazons ec2.

It seems you have extensive knowledge of cfd and openfoam, what is your experience?

You would need to clarify what do you mean by experience? Experience as in "what is your opinion of ..." or as in "how many years have you been doing...".

To keep to the thread, my experience with openFoam is quite positive (although limited to the last few years). I tend to limit myself to the existing solvers - I am not too much of a compiler of other people software (particularly when there is a lot of dependencies - although I am trying to compile ParaView at the moment). I am using openFoam on Windows (mainly) and ubuntu (on amazon ec2 and a local very old computer).

My application field was focused on HVAC applications up until last year, but has been focused on car aerodynamic recently.

My centre of interest is in the software development and coupling of tools together. Part of my recent projects includes:

- Khamsin, a SketchUp Plugin for CFD Modelling - which couples to openFoam as one of the CFD engine;
- Aerodynamic on Demand - a CFD based aerodynamic calculator for cars again based on openFoam and using amazon ec2;
- Khamsin Virtual Racecar Challenge - a virtual racing car challenge (for fun).

Feel free to check my profile on LinkedIn if you want a full detail of my experience.

Friendly nag. :)

That looks interesting. Any thoughts on how useful Khamsin is? Any screenshots? A good tool like that could push me to learn Sketchup (vs Solidworks).

I am not the best person to advise on how "useful" Khamsin is. You can have a look at the work done by Andy Laurence Blog. He initially used Khamsin (looked for older post) and moved recently to Aerodynamic on Demand. These are two different front ends to more/less the same CFD engine/

The overwhelming feedback is that it takes a few hours and a bit of frustration to get the setup right with Khamsin - my apologies. See CFD With Sketchup - YouTube for example.

Both of the above are unaffiliated.

If you have a bit of time, I would recommend watching one of the analysis video. A good one is: CFD Modelling of a 250cc kart - YouTube or any other from the YouTube channel http://www.youtube.com/user/HibouSoftware. Otherwise let me know and I can send you a pdf of the documentation/tutorial.

Sketchup vs Solidworks: I will doing a web presentation on some of the limitations of SketchUp for CFD applications that I have identified while using it in the future. A main one is its inability of properly handling curves... Best way to keep informed would be through twitter @HibouSoftware or Google+ (info@hibouscientificsoftware.com.au).