Difference between revisions of "Tutorials/Before Getting Started"

From OpenFOAMWiki
(revised the already written text and added a bit more structure)
(OK, only the final chapter to go...)
Line 38: Line 38:
  
  
But even if you find a good GUI, sooner or later you will need to have the following state of mind when it comes to using OpenFOAM technology:
+
But even if you find a good GUI, sooner or later you will need to have the following ''state of mind'' when it comes to using OpenFOAM technology:
 
# First of all, do not think about this as being ''too hard'' or ''too complex''. But it can (and it will) take a considerable amount of time to get to know it well enough.
 
# First of all, do not think about this as being ''too hard'' or ''too complex''. But it can (and it will) take a considerable amount of time to get to know it well enough.
# ''Complexity is in the eye of the beholder'' - This to say that you should never, '''ever''', try to solve your final problem directly... at least not until you've gained enough experience.
+
# ''Complexity is in the eye of the beholder'' - This to say that you should never - '''not ever''' - try to solve your final problem directly... at least not until you've gained enough experience.
 
#* And experience can only be gained if you start with one or more very simple example cases and then gradually add complexity, one detail at a time.
 
#* And experience can only be gained if you start with one or more very simple example cases and then gradually add complexity, one detail at a time.
 
# Do not ''speed through'' any available instructions you can find. You should always carefully read and study the available instructions when it comes to OpenFOAM technology and CFD.
 
# Do not ''speed through'' any available instructions you can find. You should always carefully read and study the available instructions when it comes to OpenFOAM technology and CFD.
Line 52: Line 52:
  
 
== Common mistakes ==
 
== Common mistakes ==
'''TODO'''
+
When it comes to mathematics, science and computers, the smallest detail can be the difference between success and failure. When it comes to OpenFOAM, the following are some of the most common mistakes:
 +
; Forgetting about units:
 +
: OpenFOAM mostly works in SI units. So make sure that:
 +
:# Your geometry should be in [http://en.wikipedia.org/wiki/Metre metre], or at least that the final mesh should be in [http://en.wikipedia.org/wiki/Metre metre].
 +
:# Check the units defined with the usual vector structure that OpenFOAM uses, e.g. <tt>[0 2 -2 0 0 0]</tt>, which is usually defined for field files and for some parameters in dictionary files.
 +
 
 +
; Punctuation in dictionary and field files to be read by OpenFOAM:
 +
: OpenFOAM tries to keep things simple enough:
 +
:* Space character is used as a separator between values;
 +
:* Semi-colons (<tt>;</tt>) are the standard line terminators for the definition of a particular value.
 +
:* Brackets (<tt>{}</tt>) are the standard dictionary block delimiters.
 +
:* Curved parenthesis (<tt>()</tt>) are the standard vector, matrix and list grouper.
 +
:* Square parenthesis (<tt>[]</tt>) are usually for defining dimensions and units.
 +
 
 +
A somewhat group of examples of a '''bad definition of values''' in a dictionary files:
 +
<pre>
 +
  type Fixed Value
 +
  velocity 0, 2, 0;
 +
  acceleration 0.2 m/s2;
 +
</pre>
 +
The correct corresponding settings would be, for example:
 +
<pre>
 +
  type fixedValue;
 +
  velocity (0 2 0);
 +
  acceleration [0  1 -2 0 0 0] 0.2;
 +
</pre>
 +
 
 +
; Spaces in paths:
 +
: OpenFOAM ''sort-of doesn't like'' names with spaces and that start with numbers. This is because the complexity of verifying the validity of such names would increase greatly and could reduce computational performance. For example:
 +
:* '''Bad''': {{tt|/home/ofuser/Desktop/My very First test simulation}}
 +
:* '''Good''': {{tt|/home/ofuser/Desktop/My1stTestSimulation}}
 +
 
 +
 
 +
; Names with spaces,
 +
: Letter case is extremely important. For example, ''Vector'' and ''vector'' are not the same word for OpenFOAM's dictionary parsing mechanism.
  
  
 
== Verify/validate your results ==
 
== Verify/validate your results ==
'''TODO'''
+
One or more of the following are advisable:
 +
# Whenever possible, you should always compare the case set-up you're using, with the results achieved for the same case in a real experimental environment.
 +
# Always check if a group of settings works as intended. For example:
 +
## Imagine you're testing new inlet boundary condition (i.e. one that you don't have experience with), for making the fluid flow from one inlet to another outlet, within a complex 10 metre pipe.
 +
## Then you should first test with a small test case, such as a simple cube with 1 metre on each side, and check if the results are correct.
 +
## This way you'll prove that the new boundary condition works as expected.
 +
# Verify the results with a higher resolution mesh, to see how much the results will change. For more details on this, search for more details about this topic: ''Convergence and Mesh Independence Study''.
 +
# Models have limitations on the ranges of simulations where they can be used. For example, the turbulence models of the categories RANS, LES and DNS have all their own purposes, for simulating different scales of fluid interaction. Therefore, you should study, validate, verify and confirm, in order to be very well aware of how well your simulation represents the real/physical experiment.
  
  
 
== Mathematical constraints ==
 
== Mathematical constraints ==
'''TODO'''
+
Here the details can get a bit weirder. CFD relies on numerical methods, which are applied to computational calculations, for solving the various equations that need to be solved. In addition, most methods used in CFD for solving fluid flow will rely on creating a discrete representation of the physical experiment you're trying to simulate.
 +
 
 +
Not very clear, was it? Then here is a simplified analogy: Digital Photography
 +
# In digital photography we have to rely on pixels for representing our image.
 +
# With each new generation of digital cameras, more resolution is possible for each individual picture, which means that more quality will have the final photo.
 +
# If for each inch of length you have 10 pixels, then your image won't have much quality. For example, this is an image with only 31x36 pixel: <br> [[File:before getting started - example 00.png|thumb|31px|center]]
 +
# But if you have a resolution of 100 pixels per inch, you will get a lot more detail. But it depends on if your lens is able to provide that quality. For example: <br> [[File:before getting started - example 01.png|thumb|204px|center|204x197 pixel picture, digitally scaled from the image 31x36 pixel.]] [[File:before getting started - example 02.png|thumb|204px|center|204x197 pixel picture, digitally scaled from an image of roughly 100x100 pixel.]]
 +
# All 3 pictures are essentially the representation of the same object, with different resolutions and resulting quality.
 +
# Try for yourself with image editing software to see what kinds of transformations you can do images and the resulting quality you get.
 +
 
 +
 
 +
This is pretty much what the first paragraph of this section is trying to explain: the numerical methods to be used for modelling your simulation, also depend on the mesh resolution you have available and the quality you're aiming for, as well as any additional mathematical treatments are put into place to try and improve the quality of the resulting resolution. As for figuring out which one is the right one... well, that's an art akin to photography ;)
  
  
 
== Computational limitations ==
 
== Computational limitations ==
'''TODO'''
+
All of the following details in a computer are important for achieving results when using CFD:
 +
; RAM
 +
: Acronym for Random Access Memory, is the main processing memory of your computer. This is where the CPU will be storing its intermediate calculations. How much RAM and how fast it is, will limit how many cells you mesh can have and how fast you can run the simulation.
 +
 
 +
; CPU
 +
: Acronym for Central Processing Unit. Currently we're in the middle of a development phase in computer history where the CPUs are absorbing more and more features, such as:
 +
:* Dedicated calculation units for multimedia operations (audio, video, encoding, network);
 +
:* Dedicated calculation structures for vector mathematics (where blocks of vector can be operated explicitly in parallel);
 +
:* Dedicated graphics processing units.
 +
: Anyway, aside from all of these neat ''futuristic'' features, what matters in the CPU is usually the top speed it can achieve with all of the cores in parallel, and how efficiently it can access the RAM. Essentially, this will dictate how fast you can perform simulations.
 +
: In addition to this, it also depends on how many bits your CPU can process in each cycle. The usual kinds of bit capacity are 32-bit and 64-bit processors.
 +
 
 +
; Disk performance and dimensions
 +
: This is where you can permanently store the data, both initial settings, ''snapshots'' of intermediate results, as well as the final results. Therefore, it all depends on how much disk space your simulations will need and how frequently they will store data to disk.
 +
 
 +
 
 +
Then there are the limitations of numerical precision, which usually sums up to this: Are you using single or double precision?
 +
* Single precision: also named 32-bit floating point values, which are roughly limited to 1e-38 to 1e38 and 8-9 decimal digits.
 +
* Double precision: also named 64-bit floating point values, which are roughly limited to 1e-308 to 1e308 and 14-16 decimal digits.
 +
 
 +
This essentially dictates the quality of the results, which might strongly depend on the kind of simulation you're performing. How can you know which one is better for you? Well, what did you read in the previous section [[#Mathematical constraints|Mathematical constraints]], you should at least create a simple test case that represents your desired simulation and test using 32 or 64-bit.
 +
 
 +
Either way, people nowadays mostly use 64-bit floating point values, because it allows them to use today's 64-bit CPUs to the fullest, even if it requires twice as much memory as single precision. The benefit of using 32-bit would only come from a need to have results as fast if and as possible.
 +
 
 +
 
 +
All of this information is for you to keep in mind that you should try to be fully aware of the limitations you're dealing with. Continuing the example given in the previous section [[#Mathematical constraints|Mathematical constraints]], this is similar the limitations of digital photography are:
 +
* How much space you have in the SD card, for storing pictures.
 +
* How many pictures you need to take per second.
 +
* How much resolution do you need in each one of your pictures. In other words, what's the level of detail you need?
 +
* Can post-processing techniques help getting you acceptable photos, in case you cannot use the desired hardware?
  
  

Revision as of 17:28, 4 January 2015

1 Introduction

Actually, this is more of a disclaimer than an introduction, because:

  1. This page aims to give you, the reader, a good sense of direction when it comes to using OpenFOAM technology.
  2. This page will not explain any specific details about how to use OpenFOAM and any Forks and Variants is has (which is why we'll refer to it as OpenFOAM technology).
  3. This page is an attempt at making you, the reader, better prepared on how to get started on using OpenFOAM technology.


Requirements before you continue reading this page (feel free to skip this at your own risk):

  1. Be aware that OpenFOAM technology is open and free as a technology and as in freedom, as described by the Free Software Foundation: What is free software?
    • This does not mean that it's cost-free. The primary cost associated to using OpenFOAM technology is Time... and since time is money, that's where its real costs reside.
  2. OpenFOAM and any and all of its variants and forks are bound by the GNU General Public License. It's advisable that you get a bit familiar with what this allows you to do or not, as described here: Frequently Asked Questions about the GNU Licenses
  3. OPENFOAM® is a trade mark. So much that you'll see this very often:
    This offering is not approved or endorsed by OpenCFD Limited, the producer of the OpenFOAM software and owner of the OPENFOAM® and OpenCFD® trade marks.
  4. Be prepared to read a lot of information!


2 Names and References

The following are the primary references when it comes to OpenFOAM technology:

Beyond this, there are several forks and variants, which are documented here: Forks and Variants - including the details on what a fork and variant is in this context.


3 State of Mind

Looks like a weird section name, isn't it? Well, this is because OpenFOAM technology defies the currently traditional mind set of most software users.

You're probably more familiar with friendly and forgiving Graphical User Interfaces (GUI), with varying degrees of friendliness. And you possibly want to use OpenFOAM technology in Windows or Mac OS X. Well, if you're looking for any or all of those, then have a look at the following wiki pages:


This is because the primary target Operating System for OpenFOAM is Linux and there is no official GUI. The reasons for this are explained here:


But even if you find a good GUI, sooner or later you will need to have the following state of mind when it comes to using OpenFOAM technology:

  1. First of all, do not think about this as being too hard or too complex. But it can (and it will) take a considerable amount of time to get to know it well enough.
  2. Complexity is in the eye of the beholder - This to say that you should never - not ever - try to solve your final problem directly... at least not until you've gained enough experience.
    • And experience can only be gained if you start with one or more very simple example cases and then gradually add complexity, one detail at a time.
  3. Do not speed through any available instructions you can find. You should always carefully read and study the available instructions when it comes to OpenFOAM technology and CFD.
  4. Every single detail matters more than you're likely willing to care about. This will be exemplified in the next section Common mistakes.
  5. Have a journal where you write down of what you've done, what errors you've made and how you've fixed them. Sooner or later, you'll repeat those same errors and/or have to reproduce the same results.
  6. Keep in mind that Computational Fluid Dynamics (CFD) and OpenFOAM technology are tools of science and mathematics, through the use of digital/computational power. In other words:
    • Science: You should always keep in mind that what you're using and doing needs to be validated whenever possible. More details in section Verify/validate your results.
    • Mathematics: CFD relies on tons of mathematics, specially computational mathematics. More details in section Mathematical constraints
    • Computational power: RAM, disk space, numerical precision, and so on. These limitations will dictate what you can or cannot do with CFD and OpenFOAM technology. More details in section Computational limitations.


3.1 Common mistakes

When it comes to mathematics, science and computers, the smallest detail can be the difference between success and failure. When it comes to OpenFOAM, the following are some of the most common mistakes:

Forgetting about units
OpenFOAM mostly works in SI units. So make sure that:
  1. Your geometry should be in metre, or at least that the final mesh should be in metre.
  2. Check the units defined with the usual vector structure that OpenFOAM uses, e.g. [0 2 -2 0 0 0], which is usually defined for field files and for some parameters in dictionary files.
Punctuation in dictionary and field files to be read by OpenFOAM
OpenFOAM tries to keep things simple enough:
  • Space character is used as a separator between values;
  • Semi-colons (;) are the standard line terminators for the definition of a particular value.
  • Brackets ({}) are the standard dictionary block delimiters.
  • Curved parenthesis (()) are the standard vector, matrix and list grouper.
  • Square parenthesis ([]) are usually for defining dimensions and units.

A somewhat group of examples of a bad definition of values in a dictionary files:

   type Fixed Value
   velocity 0, 2, 0;
   acceleration 0.2 m/s2;

The correct corresponding settings would be, for example:

   type fixedValue;
   velocity (0 2 0);
   acceleration [0  1 -2 0 0 0] 0.2;
Spaces in paths
OpenFOAM sort-of doesn't like names with spaces and that start with numbers. This is because the complexity of verifying the validity of such names would increase greatly and could reduce computational performance. For example:
  • Bad: /home/ofuser/Desktop/My very First test simulation
  • Good: /home/ofuser/Desktop/My1stTestSimulation


Names with spaces,
Letter case is extremely important. For example, Vector and vector are not the same word for OpenFOAM's dictionary parsing mechanism.


3.2 Verify/validate your results

One or more of the following are advisable:

  1. Whenever possible, you should always compare the case set-up you're using, with the results achieved for the same case in a real experimental environment.
  2. Always check if a group of settings works as intended. For example:
    1. Imagine you're testing new inlet boundary condition (i.e. one that you don't have experience with), for making the fluid flow from one inlet to another outlet, within a complex 10 metre pipe.
    2. Then you should first test with a small test case, such as a simple cube with 1 metre on each side, and check if the results are correct.
    3. This way you'll prove that the new boundary condition works as expected.
  3. Verify the results with a higher resolution mesh, to see how much the results will change. For more details on this, search for more details about this topic: Convergence and Mesh Independence Study.
  4. Models have limitations on the ranges of simulations where they can be used. For example, the turbulence models of the categories RANS, LES and DNS have all their own purposes, for simulating different scales of fluid interaction. Therefore, you should study, validate, verify and confirm, in order to be very well aware of how well your simulation represents the real/physical experiment.


3.3 Mathematical constraints

Here the details can get a bit weirder. CFD relies on numerical methods, which are applied to computational calculations, for solving the various equations that need to be solved. In addition, most methods used in CFD for solving fluid flow will rely on creating a discrete representation of the physical experiment you're trying to simulate.

Not very clear, was it? Then here is a simplified analogy: Digital Photography

  1. In digital photography we have to rely on pixels for representing our image.
  2. With each new generation of digital cameras, more resolution is possible for each individual picture, which means that more quality will have the final photo.
  3. If for each inch of length you have 10 pixels, then your image won't have much quality. For example, this is an image with only 31x36 pixel:
    Before getting started - example 00.png
  4. But if you have a resolution of 100 pixels per inch, you will get a lot more detail. But it depends on if your lens is able to provide that quality. For example:
    204x197 pixel picture, digitally scaled from the image 31x36 pixel.
    204x197 pixel picture, digitally scaled from an image of roughly 100x100 pixel.
  5. All 3 pictures are essentially the representation of the same object, with different resolutions and resulting quality.
  6. Try for yourself with image editing software to see what kinds of transformations you can do images and the resulting quality you get.


This is pretty much what the first paragraph of this section is trying to explain: the numerical methods to be used for modelling your simulation, also depend on the mesh resolution you have available and the quality you're aiming for, as well as any additional mathematical treatments are put into place to try and improve the quality of the resulting resolution. As for figuring out which one is the right one... well, that's an art akin to photography ;)


3.4 Computational limitations

All of the following details in a computer are important for achieving results when using CFD:

RAM
Acronym for Random Access Memory, is the main processing memory of your computer. This is where the CPU will be storing its intermediate calculations. How much RAM and how fast it is, will limit how many cells you mesh can have and how fast you can run the simulation.
CPU
Acronym for Central Processing Unit. Currently we're in the middle of a development phase in computer history where the CPUs are absorbing more and more features, such as:
  • Dedicated calculation units for multimedia operations (audio, video, encoding, network);
  • Dedicated calculation structures for vector mathematics (where blocks of vector can be operated explicitly in parallel);
  • Dedicated graphics processing units.
Anyway, aside from all of these neat futuristic features, what matters in the CPU is usually the top speed it can achieve with all of the cores in parallel, and how efficiently it can access the RAM. Essentially, this will dictate how fast you can perform simulations.
In addition to this, it also depends on how many bits your CPU can process in each cycle. The usual kinds of bit capacity are 32-bit and 64-bit processors.
Disk performance and dimensions
This is where you can permanently store the data, both initial settings, snapshots of intermediate results, as well as the final results. Therefore, it all depends on how much disk space your simulations will need and how frequently they will store data to disk.


Then there are the limitations of numerical precision, which usually sums up to this: Are you using single or double precision?

  • Single precision: also named 32-bit floating point values, which are roughly limited to 1e-38 to 1e38 and 8-9 decimal digits.
  • Double precision: also named 64-bit floating point values, which are roughly limited to 1e-308 to 1e308 and 14-16 decimal digits.

This essentially dictates the quality of the results, which might strongly depend on the kind of simulation you're performing. How can you know which one is better for you? Well, what did you read in the previous section Mathematical constraints, you should at least create a simple test case that represents your desired simulation and test using 32 or 64-bit.

Either way, people nowadays mostly use 64-bit floating point values, because it allows them to use today's 64-bit CPUs to the fullest, even if it requires twice as much memory as single precision. The benefit of using 32-bit would only come from a need to have results as fast if and as possible.


All of this information is for you to keep in mind that you should try to be fully aware of the limitations you're dealing with. Continuing the example given in the previous section Mathematical constraints, this is similar the limitations of digital photography are:

  • How much space you have in the SD card, for storing pictures.
  • How many pictures you need to take per second.
  • How much resolution do you need in each one of your pictures. In other words, what's the level of detail you need?
  • Can post-processing techniques help getting you acceptable photos, in case you cannot use the desired hardware?


4 How to get started with OpenFOAM

Learning how to use OpenFOAM is something that has to be done gradually, whether you like it or not.

TODO