Download the tutorial from our GitHub tutorial repository.

 

Introduction

In this post, the coupling of an OpenFOAM (v 4.0) simulation and Dakota (v6.4) optimization software will be discussed. The optimization goal is to find the angle-of-attack (AoA) value that yields to the minimum drag coefficient of the airfoil. The case presented here is the RANS simulation of the flow around the NACA 5410 airfoil. This case is presented for tutorial purposes to establish the connection between the simulation I/O parameters (OpenFOAM) and the optimization I/O parameters (DAKOTA). In general, Dakota can be coupled with any simulation model regardless of the physics. Sometimes, the simulation model is referred to as the black box model, somewhat emphasizing the fact that Dakota is a flexible tool that can be used in various cases. We hope it will serve as an understanding point for OpenFOAM+DAKOTA coupling. For more information about Dakota, please check out our blog post.

Writing a VTK file in Serial mode tutorials can be found on VTK example page and many various websites. However, a detailed example on how to output solution files in parallel (i.e. MPI) is almost nonexistent. The only related example can be found on VTK Wiki page, but it is incomplete and misleading. So we wanted share a tutorial on this post. If you find this example too basic or trivial, please contact us for more complex examples. We will be sharing an updated version of this post with our in-house developed library "PAVLOV" in the future.

The following example shows how to write an unstructured grid VTK file (.pvtu) in parallel using MPI:

In this tutorial, the goal is to output a data file in VTK format where each processor generates its own data from its partition. (4 processors were used) .

We start with initializing MPI as usual;

Then each processor defines its own point and cell array as if it is in serial mode. Then while writing its own grid file from its partition in ".vtu" format, the naming convention becomes important. The figures below show each vtu file separately.

Here each processor should give a file name with "filename_(mpi_rank).vtu" which will hint the "filename.pvtu" in which files it should merge while visualizing in an visualization software (i.e. Paraview, VisIt). 

Finally, the most important step is the writing the ".pvtu" file by a single processor (which can be root, where mpi_rank=0), which help to "stitch" all individual files into a unified handler and used as the main file to be opened by the visualization software. 

After importing the main ".pvtu" file, one can see below that all the partitions show up as single unified mesh.

As a final remark, the main motivation behind writing the output files in parallel comes down to Amdahl's law which states that the maximum speedup a parallel software can achieve is limited by the fraction of serial portion it has. Thus, parallel VTK effectively decreases this serial portion of a software (which is usually non-negligible) and helps it to scale up better.

We are including all the source file that is used to generate this example on our github page (click DOWNLOAD , follow the link and click download on the github page). Once downloaded, please refer to the readme inside the tarball for compile and run instructions.

Dakota (Design Analysis Kit for Optimization and Terascale Applications) is a very comprehensive open-source library for optimization, uncertainty quantification, sensitivity analysis and calibration purposes. The effort started in 1994 by Sandia National Laboratories based in New Mexico. Dakota is released under GNU Lesser General Public License.

As it is stated in it's manual Dakota is the first generic optimization software that is available for wide range of engineering applications. Thanks to it's rich content it can be coupled with any simulation software via scripting.  Check out our Dakota-OpenFOAM and Dakota-SU2 tutorials.

Below is a snippet used for an input file for DAKOTA for one of our tutorials coupling OpenFOAM and DAKOTA.

 

Citing from their website; "Python is a programming language that lets you work more quickly and integrate your systems more effectively. You can learn to use Python and see almost immediate gains in productivity and lower maintenance costs."

We mainly use python at Rotorbit as a scripting tool within our software which quickens the file movement, compilation (e.g. Make, CMake), output etc.. stages. Below is a part of our main python script we have implemented in our solver. It is a high level language. It has been voted to be even taught to elementary level students to help them become familiar with programming from the early stages of their life since programming knowledge is becoming widely required. For further tutorials and documentation refer to python website.

To give a short example, we use python script "gauss.py" for our GAUSS software to manage compilation, running, output generation. We invoke the command;

$ python gauss.py -m

to compile the software, and below you can see a small portion of the part corresponding to the "-m" argument.  

Citing from their website "Valgrind is an instrumentation framework for building dynamic analysis tools. There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail. You can also use Valgrind to build new tools."

We are using Valgrind mainly to check for memory leaks which can be a serious issue if the complexity of the program is high. The best practice is to check for memory leaks periodically during development and starting from the early stages.

Please refer to the website for detailed documentation and tips.

For sample execution command;

$ valgrind --log-file="valgrind.out" --track-origins=yes ./maestro.x > my_prog.out

Dear Visitors,

As a first post, we wanted to talk briefly on the motivation of our upcoming posts.

We are a team of engineers working at Rotorbit Engineering (www.rotorbit.com). Our team has considerable experience in academia and industry conducting computational work. We use a large number of tools, approaches, libraries (which are almost exclusively open-source) in our daily operations and are constantly trying hard to improve our working philosophy with newly emerging ideas.

We are starting to maintain a blog for three main reasons;

1) Put pressure on ourselves to share our approaches in a clear and organized way

2) Help people out with new ideas to improve their work

3) Get feedback from people for improving our working philosophy

Our posts will include a rather large family of computational tools, libraries, techniques, etc. We are pretty sure some blogs will be familiar to you or seem trivial. Nonetheless, we hope that the totality of our posts will be helpful for everyone, ranging from people who has just delved into  computational research as well as seasoned people which some of our posts might compliment their computational arsenal with new approaches, examples or tools. We will also be sharing example cases with individual tools or a combination of them on github (https://github.com/rotorbit).

That being said thank you very much for visiting our website, please do not hesitate to drop your comments below the posts with questions or suggestions. The picture above is hanging on the wall of our office, it should give you an idea on the topics will be discussing in the future.

Rotorbit Team