Dakota - OpenFOAM Coupling

By 5:43 AM , , , , ,






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.

    Layout

    You can see the layout of components used in this tutorial case.


    Solution

    Before we delve into the case in more detail, the flow conditions and optimization constraints are given as follows:
    • Freestream Velocity Magnitude: 166.2 m/s
    • Chord Length: 0.4 m
    • Density: 1.177 kg/m^3
    • Domain Radius: 3 m 
    • Kinematic Viscosity:  1.343 m^2/s
    • Freestream Temperature: 300 K
    • AoA range: [-5.0; 5.0], with initial AoA of 4.0 (all in degrees) 
    As turbulence model, kOmegaSST is used in OpenFOAM. More details about the flow conditions can be found in the baseOpenFOAM/ directory in the case tutorial. 

    Case Directory

    The case directory can be downloaded from our GitHub tutorial repository.  After this, you should decompress the tar archive and get into the directory. You can use the following commands:


    The directory downloaded from GitHub contains all the necessary files and dictionaries, except the mesh file due to it's size. You can either create the mesh by ./createMesh command or you can download the mesh file from our Google Drive link. However, if you choose to create the mesh with the script, you should be wary that it may take considerable amount of time depending on your computer resources. If you choose to download it, you should decompress the polyMesh.tar.gz as stated above and move it under the constant/ directory. Assuming that you downloaded the mesh file into the case directory, you can use following commands to decompress and move:


    So, in any situation whether you downloaded the mesh or created it by the script provided (createMesh), you should have a polyMesh/ directory located under constant/ directory, just like a regular OpenFOAM case.

    In order to communicate Dakota and OpenFOAM, the drag forces as the result of the CFD run and the new AoA value that Dakota dictates for the next CFD run must be parsed back and forth. The parsing of drag force coefficient is needed in every step of the iteration. Here, the iteration means the every single complete CFD run with corresponding input parameters (in this case AoA) provided by Dakota.

    Before running Dakota, let's take a look at the the case directory in more detail. Here, you can see 6 different files and directories. These are:

    • airfoilDrag.in
    • baseOpenFOAM
    • cleanCase
    • results/
    • simulator_script
    • templatedir/

    This includes all the necessary dictionaries and files except the mesh file due to it's size. You can create the mesh with the included scripts and OpenFOAM dictionaries. If you choose to do so, you don't have to download any other file, but mesh creation may take considerable  amount of time depending on your computer resources.

    airfoilDrag.in

    This is the configuration file Dakota. This file includes the options about optimization part. In the beginning of the file there is "method," section which contains optimization package ("conmin_frcg"), which is Fletcher-Reeves conjugate gradient method in this case.

    Also you can see the AoA range (-5.0; +5.0) that is constrained for optimization algorithm and the initial AoA value (4.0) are set under the variables keyword. 

    In the "interface" section, you can see the analysis driver script, which drives all the operation in a chain reaction fashion. the simulator_script is responsible for creating angles.dat file via the angles.dat.template file which describes the rule for writing angles.dat.  The angles.dat file is then read by our small C++ codes in the createFiles/ directory which is responsible for creating the 0org/U file which specifies the initial condition for velocity field.  The role of createFiles/ directory will be made clear in the following sections.

    As you might have noticed, simulator_script works in the current CFD iteration case that is populated with the contents of baseOpenFOAM/ directory. Obviously, baseOpenFOAM/ directory serves as the base case for physical simulation. This approach is useful for keeping the coupled case directory clean and it also makes it easier to change the simulation case.

    baseOpenFOAM/

    As mentioned in the previous section, this is the base case for physical simulation, in this case a compressible flow around NACA 5410 airfoil. It is a 2D Reynolds-Averaged Naiver-Stokes (RANS) case with kOmegaSST model.  Other than the createFiles/ directory it is a standart OpenFOAM case with force coefficient calculation. You can check the case directory for more details.
    In createFiles/ directory there are custom C++ codes written by us to parse the newly suggested AoA value by Dakota and create the necessary dictionaries with this new AoA value. The rtbt_topo.x creates topoSetDict, U and forceCoeffs files for the current CFD run with the suggested AoA values. These files must be regenerated at the begging of each run. The topoSetDict is used to create the quarter-circle inlet, outlet, upper and lower patches for boundary conditions. AoA is given on the fixed mesh with varying patches. This variation can bee seen in the figures below.




    One last thing to mention about in the baseOpenFOAM/ directory is the Allrun script written in bash language. This script is run by simulator_script of Dakota and it controls the CFD run for each iteration. You can check out the commands in it and change the run type from default serial to parallel depending on your computer resources. It also handles the parsing of drag coefficient as the result of CFD run. The drag coefficient is than written into he QoI.dat file. Here, QoI stands for "quantity of interest". This terms stems from the optimization jargon. In some cases the parsing of end result is done by grep command in bash.  This time it is done by cat and sed commands. 

    cleanCase

    This is a very simple bash script and it's name speaks for itself. It cleans the working directory by removing the workdir.*/ directories that contain each CFD run. It also cleans other unnecessary files and prepares the coupling directory for a new run. If there is any file or result that you are interested and do not want them to be removed in the working directory, please copy them elsewhere before running this script. If you want to make a change in the simulation parameters or optimization parameters, cleanCase is a helpful tool. Also, bear in mind that it also removes the results, because the results are appended in each iteration step.

    results/

    The parsed results will be contained in this directory. This directory also contains a gnuplot script that can plot the quantity of interest real-time. After the first run is complete you can run this script to see the behavior of quantity of interest vs. iteration number. Especially for simulations with shorter run-times this can be useful.

    templatedir/

    This directory contains the template for AoA parsing. The variable in curly brackets is changed with the real results after the simulation is done. This is initiated by simulator_script. The simulator_script calls a Perl script called dprepro that comes with Dakota. simulator_script passes the variable $1  along with the template file to dprepro and it creates angles.dat

    How to Run?

    When you are in the Rotorbit_OF_Dakota/ directory you can run the coupled simulation by the following command:

    You will see the workdir.*/ directories being generated in the Rotorbit_OF_Dakota/ directory.  These are the individual CFD runs generated by the contents of baseOpenFOAM/ and the new AoA value. Note that the executions are redirected into the log files both for Dakota and OpenFOAM.

    Results

    Here shown is the result of the tutorial case for maximum of 5000 rhoSimpleFoam iterations. This setting in tutorial case is set to 1000 for economic reasons, so you may have slightly different results. The green graph shows the variation of drag coefficient with CFD run number.


    Here you can see the flowfield of the last (21st) CFD run.




    References:

    You Might Also Like

    1 comments

    1. Hello. I've tried to run your case to understand how does dakota work. However I got several mistakes concerning the name of the boundaries. When I download the polyMesh file from your link, the boundary names are: front, back, airfoil and cylinder. If I use the dakota command like this the boundaries are not recognized because in the 0 folder they have other names. So I run blockMesh to have a new Mesh and the boundaries are now: topAndBottom, inlet, outlet, front and back. If I run like this the Dakota command, it only makes two workspaces because it says that the topAndBottom doesn't exist. So I change the names in the 0 file to topAndBottom, and then it says that upper and lower are not recognized, however those boundaries are not in the mesh boundary file. How this can be? Thanks for your help, your tutorial is really good.

      ReplyDelete