diff --git a/_data/tutorials.yml b/_data/tutorials.yml index f6521272..d0968b56 100644 --- a/_data/tutorials.yml +++ b/_data/tutorials.yml @@ -26,6 +26,7 @@ - Inc_Laminar_Step - Inc_Laminar_Cavity - Inc_Streamwise_Periodic + - Inc_Species_Transport - title: Structural Mechanics tutorials: @@ -48,6 +49,7 @@ - Inviscid_3D_Constrained_ONERAM6 - Multi_Objective_Shape_Design - Unsteady_Shape_Opt_NACA0012 + - Species_Transport - title: Event Content tutorials: diff --git a/_docs_v7/Custom-Output.md b/_docs_v7/Custom-Output.md index 9610e91e..20311cd5 100644 --- a/_docs_v7/Custom-Output.md +++ b/_docs_v7/Custom-Output.md @@ -136,11 +136,11 @@ For the compressible Navier-Stokes solver (i.e. `SOLVER=NAVIER_STOKES`), a **non | `DRAG` | Total Drag coefficient. | `AERO_COEFF` | | `LIFT` | Total Lift coefficient | `AERO_COEFF` | | `SIDEFORCE` | Total Sideforce coefficient. | `AERO_COEFF` | -| `MOMENT-X` | Total Moment around the x-axis. | `AERO_COEFF` | -| `MOMENT-Y` | Total Moment around the y-axis. | `AERO_COEFF` | -| `MOMENT-Z` | Total Moment around the z-axis. | `AERO_COEFF` | -| `FORCE-X` | Total Force in x direction. | `AERO_COEFF` | -| `FORCE-Y` | Total Force in y direction. | `AERO_COEFF` | -| `FORCE-Z` | Total Force in z direction.| `AERO_COEFF` | +| `MOMENT_X` | Total Moment around the x-axis. | `AERO_COEFF` | +| `MOMENT_Y` | Total Moment around the y-axis. | `AERO_COEFF` | +| `MOMENT_Z` | Total Moment around the z-axis. | `AERO_COEFF` | +| `FORCE_X` | Total Force in x direction. | `AERO_COEFF` | +| `FORCE_Y` | Total Force in y direction. | `AERO_COEFF` | +| `FORCE_Z` | Total Force in z direction.| `AERO_COEFF` | | `EFFICIENCY` | Total Lift-to-drag ratio. | `AERO_COEFF` | diff --git a/_docs_v7/Restart-File.md b/_docs_v7/Restart-File.md index 5ee20b21..8a7ad63c 100644 --- a/_docs_v7/Restart-File.md +++ b/_docs_v7/Restart-File.md @@ -3,9 +3,43 @@ title: Restart File permalink: /docs_v7/Restart-File/ --- + +## Saving files for restarts or adjoint runs + The SU2 binary restart format has the extension `.dat`, but it is also possible to write out restart files in a simple ASCII file format with extension `.csv`. Have a look at the [Output section](/docs_v7/Custom-Output/) to learn how to change output file formats. -The restart files are used to restart the code from a previous solution and also to run the adjoint simulations, which require a flow solution as input. In order to run an adjoint simulation, the user must first change the name of the `restart_flow.dat` file (or `restart_flow.csv` if ASCII format) to `solution_flow.dat` (or `solution_flow.csv`) in the execution directory (these default file names can be adjusted in the config file). It is important to note that the adjoint solver will create a different adjoint restart file for each objective function, e.g. `restart_adj_cd.dat`. +The restart files are used to restart the code from a previous solution and also to run the adjoint simulations, which require a flow solution as input. To save a restart file, the user needs to add the option `RESTART` to the keyword `OUTPUT_FILES`: + +`OUTPUT_FILES= RESTART` + +A restart file with the name given by the keyword `RESTART_FILENAME` is then saved at the end of the simulation, or after every number of iterations given by the keyword `OUTPUT_WRT_FREQ`. For instance, + +`RESTART_FILENAME= restart_flow` \ +`OUTPUT_WRT_FREQ= 100` + +will write the the file restart_flow.dat every 100 iterations when then the total number of iterations is larger than 100, or only once at the end of the simulation when the total number of iterations is smaller than 100. Note that the file extension (the suffix) is automatic and can be left out. +If you would like to keep copies of previously saved restart files, this is possible by setting -To restart a simulation the `RESTART_SOL` flag should be set to `YES` in the configuration file. If performing an unsteady restart the `RESTART_ITER` needs to be set to the iteration number which you want to restart from. For instance if we want to restart at iteration 100 and run the unsteady solver with 2nd-order dual time stepping method, we will need to specify `RESTART_ITER = 100` and have the restart files `solution_flow_00098.dat` and `solution_flow_00099.dat`. +`WRT_RESTART_OVERWRITE= NO` + +This option is available only for steady simulations. In unsteady simulations, the number of timesteps is appended to the filename automatically. Additional to the regular restart file, a restart file with the current iteration appended to the filename will be written every `OUTPUT_WRT_FREQ` iterations. + +## Starting a simulation from a saved solution + +When restarting the primal or starting an adjoint, the filename given by the keyword `SOLUTION_FILENAME` will be used. In order to restart the primal or start the run of an adjoint simulation, the user must therefore first change the name of the saved file, e.g. `restart_flow.dat` (or `restart_flow.csv` if ASCII format) to the filename `solution_flow.dat` (or `solution_flow.csv`) in the execution directory. It is important to note that the adjoint solver will create a different adjoint restart file for each objective function, e.g. `restart_adj_cd.dat`. +To restart a simulation the `RESTART_SOL` flag should be set to `YES` in the configuration file. + +`RESTART_SOL= YES` \ +`SOLUTION_FILENAME= solution_flow` + +If performing an unsteady restart the `RESTART_ITER` needs to be set to the iteration number which you want to restart from. For instance if we want to restart at iteration 100 and run the unsteady solver with 2nd-order dual time stepping method, we will need to specify `RESTART_ITER = 100` and have the restart files `solution_flow_00098.dat` and `solution_flow_00099.dat`. + +| Option value | Default value | Description | Data type | +|---|---|---|---| +| `RESTART_FILENAME` | restart.dat | filename under which the restart file will be saved | string | +| `OUTPUT_WRT_FREQ` | 250 | the frequency with which the output files will be saved | integer | +| `WRT_RESTART_OVERWRITE` | YES | overwrite the restart file or (additionally) append the iteration number to the filename | boolean | +| `RESTART_SOL` | solution | restart from file or from initial conditions | boolean | +| `SOLUTION_FILENAME` | solution.dat | filename that will be used to restart the primal or start the adjoint computation | string | +| `RESTART_ITER` | 1 | iteration number that an unsteady simulation will restart from | integer | diff --git a/_docs_v7/Theory.md b/_docs_v7/Theory.md index 3b1ebfd6..1078d5c4 100644 --- a/_docs_v7/Theory.md +++ b/_docs_v7/Theory.md @@ -12,6 +12,7 @@ This page contains a very brief summary of the different governing equation sets - [Incompressible Navier-Stokes](#incompressible-navier-stokes) - [Incompressible Euler](#incompressible-euler) - [Turbulence Modeling](#turbulence-modeling) +- [Species Transport](#species-transport) - [Elasticity](#elasticity) - [Heat Conduction](#heat-conduction) @@ -169,6 +170,34 @@ Within the turbulence solvers, we discretize the equations in space using a fini --- +# Species Transport # + +Compatible with `NAVIER_STOKES`, `RANS`, `INC_NAVIER_STOKES`, `INC_RANS` + +$$ \mathcal{R}(U) = \frac{\partial U}{\partial t} + \nabla \cdot \bar{F}^{c}(U) - \nabla \cdot \bar{F}^{v}(U,\nabla U) - S = 0 $$ + +where the conservative variables (which are also the working variables) are given by + +$$U=\left\lbrace \rho Y_1, ..., \rho Y_{N-1} \right\rbrace ^\mathsf{T}$$ + +with $$Y_i$$ $$[-]$$ being the species mass fraction. And + +$$\sum_{i=0}^N Y_i = 1 \Rightarrow Y_N = 1 - \sum_{i=0}^{N-1} Y_i$$ + +$$S$$ is a generic source term, and the convective and viscous fluxes are + +$$\bar{F}^{c}(V) = \left\{\begin{array}{c} \rho Y_1 \bar{v} \\ ... \\\rho Y_{N-1} \, \bar{v} \end{array} \right\}$$ + +$$\bar{F}^{v}(V,\nabla V) = \left\{\begin{array}{c} D \nabla Y_{1} \\ ... \\ D \nabla Y_{N-1} \end{array} \right\} $$ + +with $$D$$ $$[m^2/s]$$ being the mass diffusion. + +$$D = D_{lam} + \frac{\mu_T}{Sc_{T}}$$ + +where $$\mu_T$$ is the eddy viscosity and $$Sc_{T}$$ $$[-]$$ the turbulent Schmidt number. + +--- + # Elasticity # | Solver | Version | diff --git a/_tutorials/design_features/Inviscid_3D_Constrained_ONERAM6/Inviscid_3D_Constrained_ONERAM6.md b/_tutorials/design_features/Inviscid_3D_Constrained_ONERAM6/Inviscid_3D_Constrained_ONERAM6.md index 4e9f2d43..785f5011 100644 --- a/_tutorials/design_features/Inviscid_3D_Constrained_ONERAM6/Inviscid_3D_Constrained_ONERAM6.md +++ b/_tutorials/design_features/Inviscid_3D_Constrained_ONERAM6/Inviscid_3D_Constrained_ONERAM6.md @@ -101,7 +101,7 @@ FFD_CONTINUITY= 2ND_DERIVATIVE As the current implementation requires each FFD box to be a quadrilaterally-faced hexahedron (6 faces, 12 edges, 8 vertices), we can simply specify the 8 corner points of the box and the polynomial degree we would like to represent along each coordinate direction (x,y,z) in order to create the complete lattice of control points. It is convenient to think of the FFD box as a small structured mesh block with (i,j,k) indices for the control points, and note that the number of control points in each direction is the specified polynomial degree plus one. -In the example above, we are creating a box with control point dimensions 11, 9, and 2 in the x-, y-, and z-directions, respectively, for a total of 198 available control points. In the `FFD_DEFINITION` option, we give a name to the box ("WING"), and then list out the x, y, and z coordinates of each corner point. The order is important, and you can use the example above to match the convention. The degree is then specified in the `FFD_DEGREE` option. A view of the box with the control points numbered is in Figure (3). Note that the numbering in the figure is 1-based just for visualization, but within SU2, the control points have 0-based indexing. For example, the (1,1,1) control point in the figure is control point (0,0,0) within SU2. This is critical for specifying the design variables in the config file. +In the example above, we are creating a box with control point dimensions 11, 9, and 2 in the x-, y-, and z-directions, respectively, for a total of 198 available control points. In the `FFD_DEFINITION` option, we give a name to the box ("WING"), and then list out the x, y, and z coordinates of each corner point. The order is important, and you can use the example above to match the convention. Alternatively, [this tutorial](/tutorials/Species_Transport/) contains more in-depth information on how the numbering should be done. The degree is then specified in the `FFD_DEGREE` option. A view of the box with the control points numbered is in Figure (3). Note that the numbering in the figure is 1-based just for visualization, but within SU2, the control points have 0-based indexing. For example, the (1,1,1) control point in the figure is control point (0,0,0) within SU2. This is critical for specifying the design variables in the config file. ![Opt. ONERA FFD](../../tutorials_files/design_features/Inviscid_3D_Constrained_ONERAM6/images/onera_ffd_points.png) Figure (3): View of the control point identifying indices, which increase in value along the positive coordinate directions. Note that the numbering here is 1-based just for visualization, but within SU2, the control points have 0-based indexing. diff --git a/_tutorials/design_features/Multi_Objective_Shape_Design/Multi_Objective_Shape_Design.md b/_tutorials/design_features/Multi_Objective_Shape_Design/Multi_Objective_Shape_Design.md index e66cf8a9..8fab8f2e 100644 --- a/_tutorials/design_features/Multi_Objective_Shape_Design/Multi_Objective_Shape_Design.md +++ b/_tutorials/design_features/Multi_Objective_Shape_Design/Multi_Objective_Shape_Design.md @@ -71,7 +71,7 @@ OBJECTIVE_WEIGHT= -1.0E-7,1.0 ``` These options define a weighted sum: -1.0E-7 x (SURFACE_TOTAL_PRESSURE at the outlet) + (DRAG on the lower surface). The OBJECTIVE_FUNCTION and OBJECTIVE_WEIGHT options are set automatically during the optimization process, and are used for the calculation of the gradient. If we were starting this problem from scratch, at this point we would run the gradient method desired, in order to confirm that the gradients are being calculated as expected. In this tutorial, the discrete adjoint is used by default. When multiple objectives are specified as shown, a single adjoint solution for a 'combo' objective will be calculated, representing the gradient for the weighted sum. The upside of this is that it reduces the number of adjoint solutions required, with the downside that the contributions of different functionals to the gradient value will not be known. -Next the FFD box is defined in order to provide the design variables. The mesh is provided with the FFD box information already included, however when starting from scratch a preprocessing step using SU2_MSH is required. For further detail on FFD, see the [Constrainted Optimal Shape Design Tutorial](/tutorials/Inviscid_3D_Constrained_ONERAM6/). +Next the FFD box is defined in order to provide the design variables. The mesh is provided with the FFD box information already included, however when starting from scratch a preprocessing step using SU2_MSH is required. For further detail on FFD, see this [Unconstrained species transport tutorial](/tutorials/Species_Transport/) or [Constrainted Optimal Shape Design Tutorial](/tutorials/Inviscid_3D_Constrained_ONERAM6/). ``` % -------------------- FREE-FORM DEFORMATION PARAMETERS -----------------------% % diff --git a/_tutorials/design_features/Species_Transport/Species_Transport.md b/_tutorials/design_features/Species_Transport/Species_Transport.md new file mode 100644 index 00000000..4dd732aa --- /dev/null +++ b/_tutorials/design_features/Species_Transport/Species_Transport.md @@ -0,0 +1,315 @@ +--- +title: Unconstrained shape design of a two way mixing channel +permalink: /tutorials/Species_Transport/ +written_by: TobiKattmann +for_version: 7.2.1 +revised_by: +revision_date: +revised_version: +solver: INC_RANS +requires: SU2_CFD, FADO +complexity: advanced +follows: Inc_Species_Transport +--- + +## Disclaimer + +This Tutorial builds directly on the case given as Prerequisite on the top of the site [link](/tutorials/Inc_Species_Transport/). Therefore details to the problem setup, mesh, etc. are not repeated here. However the process outlined in this tutorial is directly applicable to many other cases using SU2. + +Instead of the python tools for finite differences or shape optimization that are part of SU2 directly, the standalone python tool [FADO](https://github.com/su2code/FADO) is used. Please follow the information on the given github repo in order to use FADO. + +## Goals + +This tutorial is a rather extensive guide covering the following steps, assuming a converging primal case is present: +1. Validation of perfect restarts as a basis for the Discrete Adjoint solver (this is done using a separate bash-script). This section focuses on code development aspects, and may be skipped by general users. +2. Setting up an FFD-box and writing it to the mesh +3. Manual testing of the mesh deformation +4. Gradient validation using FADO +5. Shape optimization using FADO + +Following these steps proved to be especially useful when developing new features as each step is an incremental rise in complexity and is much easier to debug, compared starting right away with an optimization that then fails to provide satisfactory results. + +## Resources + +You can find the resources for this tutorial in the folder [incompressible_flow/Inc_Species_Transport](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport) and the respective subfolders. + +## 1. Restart Validation + +The script [restart_validation.sh](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport/restart_validation.sh) performs 4 simulations using `species3_venturiPrimitive.cfg` to check whether primal and primal-adjoint restarts work. This script is best used with `HISTORY_OUTPUT= RMS_RES` as then the output comparison is the most straight forward. The SU2 binary is deduced from the environmental variable `SU2_RUN`, so make sure that is set correctly. With the explanation given here and the comments in the script it should be straight forward adaptable to other cases. +1. Primal simulation with n+1 timesteps. This is the ground truth of the expected residual values. Takes Residuals from the `history` file. +2. Primal simulation with n timesteps. We will restart steps 3. and 4. from this simulation. +3. Primal simulation with 1 timestep, restarted from simulation in 2nd step. Takes Residuals from the `history` file. +4. Adjoint simulation with 1 timestep, using the primal restart file from simulation in 2nd step. The primal residuals that are printed in the screen output are taken for comparison. + +When using the recommended `HISTORY_OUTPUT= RMS_RES` the output should provide the following: +``` +-5.010542647 -4.537626591 -4.207538398 0.4686163065 -6.594021422 0.4978738082 -5.253262361 -5.467591972 +-5.010542647 -4.537626591 -4.207538398 0.4686163065 -6.594021422 0.4978738082 -5.253262361 -5.467591972 +-5.010542647 -4.537626591 -4.207538398 0.4686163065 -6.594021422 0.4978738082 -5.253262361 -5.467591972 +``` +Where in each row the residual of each equation is listed (P, vx, vy, T, k, w, Species_0, Species_1). The primal restart (2nd row) and the adjoint primal restart (3rd row) provide identical results compared to the 'full' primal simulation (1st row). Small deviations in the last digits are not an issue, especially when higher iteration counts are used (here only 10). But if the adjoint restart provides a clearly different result then this should be debugged before attempting a gradient validation or even optimization. + +The config option `OUTPUT_PRECISION= 16` can be set to compare more digits if necessary. + +Execute the scipt by: +``` +$ bash restart_validation.sh +``` + +## 2. FFD-Box Setup + +The setup is fairly simple when following some simple rules. The additional block of code necessary to write the FFD box is given below. Essentially, there are only 3 options (`FFD_DEFINITION`, `FFD_DEGREE` and `DV_MARKER`) where user input is necessary. `DV_KIND= FFD_SETTING` and `DV_PARAM= ( 1.0 )` are fixed and not to be changed. + +``` +% -------------------- FREE-FORM DEFORMATION PARAMETERS -----------------------% +% +% FFD box definition: 3D case (FFD_BoxTag, X1, Y1, Z1, X2, Y2, Z2, X3, Y3, Z3, X4, Y4, Z4, +% X5, Y5, Z5, X6, Y6, Z6, X7, Y7, Z7, X8, Y8, Z8) +% 2D case (FFD_BoxTag, X1, Y1, 0.0, X2, Y2, 0.0, X3, Y3, 0.0, X4, Y4, 0.0, +% 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0) +% Start at the lowest leftest corner and turn counter-clockwise +FFD_DEFINITION= (BOX, \ +0.065, 0.01, 0.0, \ +0.15, 0.01, 0.0 \ +0.15, 0.02, 0.0, \ +0.065, 0.02, 0.0, \ +0.0, 0.0 ,0.0, \ +0.0 ,0.0, 0.0, \ +0.0, 0.0, 0.0, \ +0.0, 0.0, 0.0 ) +% +% FFD box degree: 3D case (i_degree, j_degree, k_degree) +% 2D case (i_degree, j_degree, 0) +FFD_DEGREE= (6, 1, 0) +% +DV_KIND= FFD_SETTING +% +% Marker of the surface in which we are going apply the shape deformation +% NOTE: for deformation the outlet should be a MARKER_SYM to hinder the mesh being ripped apart. +DV_MARKER= ( wall ) +% +% Parameters of the shape deformation +% - FFD_SETTING ( 1.0 ) +% - FFD_CONTROL_POINT ( FFD_BoxTag, i_Ind, j_Ind, k_Ind, x_Disp, y_Disp, z_Disp ) +DV_PARAM= ( 1.0 ) +``` + +`FFD_DEFINITION`: The first input to this option is the FFD-Box name. Here simply `BOX` was chosen. Following are the 4 (or 8 in 3D) corner points of the FFD box. The order of how the points are written is crucial. The FFD-box points are addressed via i-j-k indices and for keeping the minimum leftover sanity it of course is highly desirable to have these i-j-k indices align with the x-y-z cartesian axes. Or, in case the FFD box sides do not coincide with the cartesian axes, you know how the i-j-k indices work. +Now assuming FFD-sides align with cartesian axes. The first point in `FFD_DEFINITION` has to be the corner point with the lowest x,y,z-value. The second point is the point following the x-axes only (i.e. keeping y and z constant). Like that the i-index coincides with the x-axes. The third point is found following the y-axes starting from the previous 2nd point (keeping x and z constant). The fourth point is the remaining on that z-constant plane. In 3D follow the first point in z-direction and repeat the process on the higher z-plane. In 2D the process can be explained simplified by: Start with the point with smallest x,y-value and turn counter-clockwise. + +`FFD_DEGREE`: Determines the number of FFD-Box points per i-j-k-index. The degree plus 1 gives the number of points used. Note: for ease of manual use it is highly recommended to start with a low amount here. Using more once the process is dialed in, is no problem. + +`DV_MARKER`: Boundary markers that are going to be deformed by the FFD-Box. Note that the Mesh deformation in SU2 is a 2-stage process: +1. The FFD-Box deforms only the boundary mesh nodes that are inside of the initial FFD-Box. These nodes are stored at the bottom of the `.su2` mesh that contain the FFD-Box. +2. The deformed boundary from the previous step is now boundary condition for a Linear Elasticity style volume mesh morpher. + +This FFD box is written to `MESH_OUT_FILENAME` by calling: +``` +$ SU2_DEF .cfg +``` + +![FFD-Box](../../tutorials_files/design_features/Species_Transport/images/FFD-Box-indicators.jpg) +Figure (1): FFD-Box with fixed points (red) and allowed deformation direction indicated by arrows. + +## 3. Mesh deformation test + +Before attempting a gradient validation or optimization it is good practice to check whether the mesh deformation process creates valid and good quality meshes. It is also possible to already check reasonable preliminary bounds for FFD values, that can be set in an optimization. This can be done in a manual process which is rather simple. + +First, some general FFD-Box deformation parameters. Additions are `FFD_TOLERANCE`, `FFD_ITERATIONS` and `FFD_CONTINUITY` which was set to `USER_INPUT` in order to not fix any points at all. With that option one can manually fix FFD-Box points using `FFD_FIX_I`/`J`/`K` options but this process can also be done without that options as will be shown below. + +``` +% -------------------- FREE-FORM DEFORMATION PARAMETERS -----------------------% +% +% Tolerance of the Free-Form Deformation point inversion +FFD_TOLERANCE= 1E-10 +% +% Maximum number of iterations in the Free-Form Deformation point inversion +FFD_ITERATIONS= 500 +% +% FFD box definition: 3D case (FFD_BoxTag, X1, Y1, Z1, X2, Y2, Z2, X3, Y3, Z3, X4, Y4, Z4, +% X5, Y5, Z5, X6, Y6, Z6, X7, Y7, Z7, X8, Y8, Z8) +% 2D case (FFD_BoxTag, X1, Y1, 0.0, X2, Y2, 0.0, X3, Y3, 0.0, X4, Y4, 0.0, +% 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0) +% Start at the lowest leftest corner and turn counter-clockwise +FFD_DEFINITION= (BOX, \ +0.065, 0.01, 0.0, \ +0.15, 0.01, 0.0 \ +0.15, 0.02, 0.0, \ +0.065, 0.02, 0.0, \ +0.0, 0.0 ,0.0, \ +0.0 ,0.0, 0.0, \ +0.0, 0.0, 0.0, \ +0.0, 0.0, 0.0 ) +% +% FFD box degree: 3D case (i_degree, j_degree, k_degree) +% 2D case (i_degree, j_degree, 0) +FFD_DEGREE= (6, 1, 0) +% +% Surface grid continuity at the intersection with the faces of the FFD boxes. +% To keep a particular level of surface continuity, SU2 automatically freezes the right +% number of control point planes (NO_DERIVATIVE, 1ST_DERIVATIVE, 2ND_DERIVATIVE, USER_INPUT) +FFD_CONTINUITY= USER_INPUT +% +% Definition of the FFD planes to be frozen in the FFD (x,y,z). +% Value from 0 FFD degree in that direction. Pick a value larger than degree if you don't want to fix any plane. +%FFD_FIX_I= (0,2,3) +%FFD_FIX_J= (0,2,3) +%FFD_FIX_K= (0,2,3) +``` + +The next set of option changes `DV_KIND`, `DV_PARAM` and `DV_VALUE` have to be specified for each Design Variable. So each of those options must have the same number of entries. + +For `DV_KIND` the tag `FFD_CONTROL_POINT_2D` is simply repeated 10 times. + +The `DV_PARAM` option lists, which of the FFD-Box points is going to be deformed and also the direction of deformation. So `(BOX, 2, 0, 0.0, 1.0)` refers to a point in the FFD-Box names `BOX` with the i-j-indices `2, 0` and will be deformed along the vector `0.0, 1.0` i.e. in y-direction. In 3D, this is of course extended by k-indices and the z-axis. +The `DV_PARAM` list can either be created by hand or by editing the output of a helping script that ships with SU2 (same directory as `SU2_CFD` binary etc.): +``` +$ python set_ffd_design_var.py -i 6 -j 1 -k 0 -b BOX -m 'wall' --dimension 2 +``` +which creates these list for the `FFD_CONTROL_POINT_2D`'s in x-y-z direction, but we are only interested in the y-direction. +``` +% FFD_CONTROL_POINT_2D (Y) +DEFINITION_DV= ( 19, 1.0 | wall | BOX, 0, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 1, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 2, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 3, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 4, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 5, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 6, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 0, 1, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 1, 1, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 2, 1, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 3, 1, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 4, 1, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 5, 1, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 6, 1, 0.0, 1.0 ) +``` +Now in order to get the `DV_PARAM` list simply the first part of each entry, namely `11, 1.0 | wall |` has to be deleted. +Here the user can also fix certain Design variables by simply not using them in the lists. Note how in the given `DV_PARAM` the first point is `(BOX, 2, 0, 0, 0.0, 1.0, 0.0 )` instead of `(BOX, 0, 0, 0, 0.0, 1.0, 0.0 )`. Like so. The first two points with the lowest i-index are fixed. + +`DV_Value` simply gives the Deformation of the respective Design Variable. If in `DV_PARAM` only unit vectors are given as deformation direction (which is the case as we only use `0.0, 1.0, 0.0`) then `DV_VALUE` is the deflection in [m] and therefore some intuition can be used when choosing testing values. + +``` +% ----------------------- DESIGN VARIABLE PARAMETERS --------------------------% +% +DV_KIND= FFD_CONTROL_POINT, FFD_CONTROL_POINT, FFD_CONTROL_POINT, FFD_CONTROL_POINT, FFD_CONTROL_POINT, FFD_CONTROL_POINT, FFD_CONTROL_POINT, FFD_CONTROL_POINT, FFD_CONTROL_POINT, FFD_CONTROL_POINT +% +% Marker of the surface in which we are going apply the shape deformation +% NOTE: for deformation the outlet should be a MARKER_SYM to hinder the mesh being ripped apart. +DV_MARKER= ( wall ) +% +% Parameters of the shape deformation +% - FFD_SETTING ( 1.0 ) +% - FFD_CONTROL_POINT ( FFD_BoxTag, i_Ind, j_Ind, k_Ind, x_Disp, y_Disp, z_Disp ) +DV_PARAM= (BOX, 2, 0, 0, 0.0, 1.0, 0.0 ); (BOX, 3, 0, 0, 0.0, 1.0, 0.0 ); (BOX, 4, 0, 0, 0.0, 1.0, 0.0 ); (BOX, 5, 0, 0, 0.0, 1.0, 0.0 ); (BOX, 6, 0, 0, 0.0, 1.0, 0.0 ); (BOX, 2, 1, 0, 0.0, 1.0, 0.0 ); (BOX, 3, 1, 0, 0.0, 1.0, 0.0 ); (BOX, 4, 1, 0, 0.0, 1.0, 0.0 ); (BOX, 5, 1, 0, 0.0, 1.0, 0.0 ); (BOX, 6, 1, 0, 0.0, +% Excluded FFD points that are fixed to keep a nice geometry and mesh +%DV_PARAM= (BOX, 0, 0, 0, 0.0, 1.0, 0.0 ); (BOX, 1, 0, 0, 0.0, 1.0, 0.0 ); (BOX, 0, 1, 0, 0.0, 1.0, 0.0 ); (BOX, 1, 1, 0, 0.0, 1.0, 0.0 ); +% +% Value of the shape deformation +% first row: lower row y-direction +% second row: upper row y-direction +DV_VALUE= 0.003, 0.003, 0.004, 0.005, 0.005, \ + 0.003, 0.003, 0.004, 0.005, 0.005 +``` + +The most important options for the volume mesh algorithm are listed below. This tutorial does not go in depth on these options. + +``` +% ------------------------ GRID DEFORMATION PARAMETERS ------------------------% +% +% Linear solver or smoother for implicit formulations (FGMRES, RESTARTED_FGMRES, BCGSTAB) +DEFORM_LINEAR_SOLVER= FGMRES +% +% Preconditioner of the Krylov linear solver (ILU, LU_SGS, JACOBI) +DEFORM_LINEAR_SOLVER_PREC= ILU +% +% Number of smoothing iterations for mesh deformation +DEFORM_LINEAR_SOLVER_ITER= 1000 +% +% Number of nonlinear deformation iterations (surface deformation increments) +DEFORM_NONLINEAR_ITER= 1 +% +% Minimum residual criteria for the linear solver convergence of grid deformation +DEFORM_LINEAR_SOLVER_ERROR= 1E-14 +% +% Print the residuals during mesh deformation to the console (YES, NO) +DEFORM_CONSOLE_OUTPUT= YES +% +% Deformation coefficient (linear elasticity limits from -1.0 to 0.5, a larger +% value is also possible) +DEFORM_COEFF = 0.0 +% +% Type of element stiffness imposed for FEA mesh deformation (INVERSE_VOLUME, +% WALL_DISTANCE, CONSTANT_STIFFNESS) +DEFORM_STIFFNESS_TYPE= WALL_DISTANCE +% +% Deform the grid only close to the surface. It is possible to specify how much +% of the volumetric grid is going to be deformed in meters or inches (1E6 by default) +DEFORM_LIMIT = 1E6 +``` + +This mesh deformation is executed via: +``` +$ SU2_DEF .cfg +``` + +In this special case the deformed produces a bad mesh at the outlet, as the mesh is 'ripped apart' there. This happens because the FFD-Box only deforms what is prescribed in `DV_MARKER` and the remaining boundaries are considered 'clamped' in the volume mesh algorithm. All boundaries? No! The boundaries in `MARKER_SYM` are allowed to move along their symmetry plane in the volume mesher.This obviously requires the boundary to form a single plane which is the case for the present outlet. So, if the outlet is prescribed as a `MARKER_SYM` for the Volume deformation step the mesh deformation will yield a reasonable mesh. + +After the mesh deformation it is advisable to also run a primal simulation on that deformed mesh, as the simulation settings (e.g. `CFL_NUMBER`) might not lead to a converging simulation anymore. For a later optimization run this testing can help keeping a converging primal through all deformations. + +![Bad mesh deformation](../../tutorials_files/design_features/Species_Transport/images/bad-mesh-deform.jpg) +Figure (2): Mesh breaks at the `outlet`, as `outlet` nodes are clamped. + +![Good mesh deformation](../../tutorials_files/design_features/Species_Transport/images/good-mesh-deform.jpg) +Figure (3): Defining the `outlet` as `MARKER_SYM` results in a satisfactory deformed mesh. + +## 4. Gradient Validation + +In the gradient validation the Discrete Adjoint gradient is compared against a Finite Difference gradient. The script `gradient_validation.py` is using FADO, so please make yourself familiar with the tutorials in that respective repository. But with the comments in the file and observing the output it is possible to reverse engineer many aspects. + +Notable here is that, first, all deformed primal computations are done and the baseline at the very end. This is done as the discrete adjoint requires the solution of the baseline mesh, so that is done right before computing the discrete adjoint gradient. +The `MARKER_SYM`-trick that was introduced in the mesh-deformation section is also applied here and also in the `SU2_DOT_AD` step. This is required to stay consistent between the mesh deformation execution and the gradient projection. + +The Objective Function used is `SURFACE_SPECIES_VARIANCE` and, as the name suggests, sums the local differences in the species mass fraction against the mean, and can therefore be used as a measure for uniform mixing. A Variance of zero would indicate perfect mixing. + +The gradient validation script is executed via: +``` +$ python gradient_validation.py +``` + +In order to postprocess the results a python script is added which compares both gradients and prints to screen and file: +``` +$ python postprocess.py +``` + +At a maximum of ~0.05% relative difference between the discrete adjoint and finite difference gradient,the agreement is excellent. +``` ++---+-------------------+-------------------+-------------------+-------------------+ +| # | DA gradient | FD gradient | absolute diff | relative diff [%] | ++---+-------------------+-------------------+-------------------+-------------------+ +| 0 | -0.0031128563 | -0.0031137331 | 0.0000008768 | 0.0281680151 | +| 1 | -0.0005406673 | -0.0005409528 | 0.0000002856 | 0.0528178961 | +| 2 | 0.0011094759 | 0.0011093871 | 0.0000000888 | 0.0080034781 | +| 3 | 0.0017487956 | 0.0017487712 | 0.0000000245 | 0.0014009004 | +| 4 | 0.0017256761 | 0.0017256695 | 0.0000000066 | 0.0003839967 | +| 5 | -0.0031128563 | -0.0031137331 | 0.0000008769 | 0.0281689729 | +| 6 | -0.0005406673 | -0.0005409528 | 0.0000002855 | 0.0528118802 | +| 7 | 0.0011094759 | 0.0011093871 | 0.0000000888 | 0.0080064097 | +| 8 | 0.0017487956 | 0.0017487711 | 0.0000000246 | 0.0014043103 | +| 9 | 0.0017256761 | 0.0017256695 | 0.0000000066 | 0.0003847820 | ++---+-------------------+-------------------+-------------------+-------------------+ +``` + +## 5. Optimization + +The setup of a shape optimization with FADO is rather straight forward once a working gradient validation script is available. It is usually a good idea to add lower and upper bounds to the design variables. In the case of FFD-Box points these values translate directly into the cartesian space and a first estimation can be made intuitively. + +The second notable extension to the gradient validation is of course the optimization setup itself. Please follow the tutorials FADO provides to learn more about the capabilities and options. But, in the provided script some additional explanations are given and more details to certain function can be printed to screen by adding e.g. `printDocumentation(driver.setFailureMode)` to the script if more information for that option are required. + +The optimization method used is [SLSQP](https://docs.scipy.org/doc/scipy/reference/optimize.minimize-slsqp.html) from the [SciPy](https://docs.scipy.org/doc/scipy/index.html) library. + +The unconstrained optimization with the objective function of `SURFACE_SPECIES_VARIANCE` (as in the gradient validation introduced) is started with the following command: +``` +$ python optimization.py +``` + +In order to compute the gradient norms of each Design iteration a `gradient_norm.py` script was added. The script will write a `gradient_norm.csv` into the folder root which. + +A helpful visualization after an optimization run is having the series of deformed meshes with their primal solution and FFD-Boxes. These solution are in their respective folders and one could tediously load every single one of them. +The script `create_Visu_symlinks.py` sweeps through the `DSN_*` folders and collects symbolic links of the primal solution and FFD-Boxes into a `visu_files` folder. The symbolic links also renames each file and appends an iteration number to the end of the filename (e.g. `ffd_004.vtk -> ../DSN_004/DEFORM/ffd_boxes_def_0.vtk`). Like so, this data can be loaded in [Paraview](https://www.paraview.org/), or probably any other post-processor, as a time series which allows for easy cycling through the designs. + +![OF and Gradient Norm](../../tutorials_files/design_features/Species_Transport/images/OF_GradNorm.png) +Figure (4): Objective Function value and Gradient Norm over optimizer iterations. Capped after 12 iterations. + +![Optimized Mesh](../../tutorials_files/design_features/Species_Transport/images/Optimized-Geometry.jpg) +Figure (5): Baseline and Optimized Mesh with the respective FFD-Boxes. + +![Optimization Cycle](../../tutorials_files/design_features/Species_Transport/images/opt_cycle.gif) +Figure (6): Optimization series from baseline to final mesh with FFD-Boxes. \ No newline at end of file diff --git a/_tutorials/design_features/Unsteady_Shape_Opt_NACA0012/Unsteady_Shape_Opt_NACA0012.md b/_tutorials/design_features/Unsteady_Shape_Opt_NACA0012/Unsteady_Shape_Opt_NACA0012.md index 1938d3c0..05050c32 100644 --- a/_tutorials/design_features/Unsteady_Shape_Opt_NACA0012/Unsteady_Shape_Opt_NACA0012.md +++ b/_tutorials/design_features/Unsteady_Shape_Opt_NACA0012/Unsteady_Shape_Opt_NACA0012.md @@ -42,6 +42,8 @@ in the [project website repository](https://github.com/su2code/Tutorials). You will need the configuration file ([unsteady_naca0012_opt.cfg](https://github.com/su2code/Tutorials/tree/master/design/Unsteady_Shape_Opt_NACA0012/unsteady_naca0012_opt.cfg)) and the mesh file ([unsteady_naca0012_FFD.su2](https://github.com/su2code/Tutorials/tree/master/design/Unsteady_Shape_Opt_NACA0012/unsteady_naca0012_FFD.su2)). +The used mesh already contains an FFD-Box. For more information on how to set up an FFD-Box on your own, please follow [this tutorial](/tutorials/Species_Transport/). + ## Tutorial ## The following tutorial will walk you through the steps required when performing a shape optimization of the NACA0012 airfoil using SU2. @@ -51,7 +53,7 @@ If you have yet to complete these requirements, please see the [Download](/docs_ ### Background ### -This test case is for the NACA0012 airfoil in viscous unsteady flow. The NACA airfoils are two dimensional shapes for aircraft wings developed by the National Advisory Committee for Aeronautics (NACA, 1915-1958, predeccessor of NASA). The NACA-4-Digit series is a set of 78 airfoil configurations which were created for wind-tunnel tests to explore the effect of different airfoil shapes on aerdynamic coefficients as drag or lift. +This test case is for the NACA0012 airfoil in viscous unsteady flow. The NACA airfoils are two dimensional shapes for aircraft wings developed by the National Advisory Committee for Aeronautics (NACA, 1915-1958, predecessor of NASA). The NACA-4-Digit series is a set of 78 airfoil configurations which were created for wind-tunnel tests to explore the effect of different airfoil shapes on aerodynamic coefficients as drag or lift. ### Mesh Description ### diff --git a/_tutorials/incompressible_flow/Inc_Species_Transport/Inc_Species_Transport.md b/_tutorials/incompressible_flow/Inc_Species_Transport/Inc_Species_Transport.md new file mode 100644 index 00000000..7a1d3fe2 --- /dev/null +++ b/_tutorials/incompressible_flow/Inc_Species_Transport/Inc_Species_Transport.md @@ -0,0 +1,169 @@ +--- +title: Species Transport +permalink: /tutorials/Inc_Species_Transport/ +written_by: TobiKattmann +for_version: 7.2.1 +revised_by: +revision_date: +revised_version: +solver: INC_RANS +requires: SU2_CFD +complexity: intermediate +follows: Inc_Turbulent_Flat_Plate +--- + + +## Goals + +Upon completing this tutorial, the user will be familiar with adding passive species transport equations to an incompressible or compressible flow problem. The necessary steps and config options will be explained with the example of a simple 2D incompressible mixing channel system. Output options will be explained as well. + +Limitations: Mixture dependent fluid properties are not available yet. The mass diffusion coefficient can only be chosen as a constant for a all species transport equations. + +## Resources + +The resources for this tutorial can be found in the [incompressible_flow/Inc_Species_Transport](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport) directory in the [tutorial repository](https://github.com/su2code/Tutorials). You will need the configuration file ([species3_primitiveVenturi.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport/species3_primitiveVenturi.cfg)) and the mesh file ([primitiveVenturi.su2](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport/primitiveVenturi.su2)). + +The mesh is created using [gmsh](https://gmsh.info/) and a respective `.geo` script is available to recreate/modify the mesh [primitiveVenturi.geo](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport/primitiveVenturi.geo). The mesh is fully structured (i.e. only contains Quadrilateral elements) with 3364 elements and 3510 points. A progression towards walls is used but the mesh resolution is for demonstration purposes only. The small size also makes it ideal for code development. + +![Mesh with boundary conditions](../../tutorials_files/incompressible_flow/Inc_Species_Transport/images/mesh.jpg) +Figure (1): Computational mesh with color indication of the used boundary conditions. + +## Prerequisites + +The following tutorial assumes you already compiled `SU2_CFD` in serial or parallel, please see the [Download](/docs_v7/Download/) and [Installation](/docs_v7/Installation/) if that is not done yet. Additionally it is advised to perform an entry level incompressible tutorial first, as this tutorial only goes over species transport + +## Background + +The geometry with two separate inlets, a junction where the two feeders meet and a nozzle leading to an outlet, resembles loosely a venturi mixer. The geometry massively simplifies these design principles. The material properties and provided mass fractions at the inlet are for demonstration purposes. + +## Problem Setup + +The material properties of the incompressible mean flow represent air: +- Density (constant) = 1.1766 kg/m^3 +- Viscosity (constant) = 1.716e-5 kg/(m-s) +- Inlet Velocities (constant) = 1 m/s in normal direction +- Outlet Pressure (constant) = 0 Pa + +The SST turbulence model is used with the default settings of freestream turbulence intensity of 5% and a turbulent-to-laminar viscosity ratio of 10. + +The material properties specific to the species transport equations are: +- Mass Diffusivity (constant) = 1e-3 m^2/s +- Mass fractions at the eastern inlet: 0.5, 0.5 +- Mass fractions at the northern inlet: 0.6, 0.0 + +## Configuration File Options + +All available options concerning species transport are listed below as they occur in the [config_template.cfg](https://github.com/su2code/SU2/blob/master/config_template.cfg). + +The options as of now are fairly limited. Species transport is switched on by setting `KIND_SCALAR_MODEL= PASSIVE_SCALAR`. The `DIFFUSIVITY_MODEL= CONSTANT_DIFFUSIVITY` is currently the only available therefore the only additional choice the value of `DIFFUSIVITY_CONSTANT`. For the `SCHMIDT_NUMBER_TURBULENT` please consult [the respective theory](/docs_v7/Theory/#species-transport). + +The number of species transport equations is not set individually but deduced from the number of values given in the respective lists for species options. SU2 checks whether the same amount of values is given in each option and solves the appropriate amount of equations. `MARKER_INLET_SPECIES` is one of these options and has to be used alongside a usual `MARKER_INLET`. For outlets, symmetries or walls this is not necessary. + +The option `SPECIES_USE_STRONG_BC` should be left to `NO` and is an experimental option where a switch to strongly enforced boundary conditions can be made. + +For `CONV_NUM_METHOD_SPECIES= SCALAR_UPWIND` a second order MUSCL reconstruction and multiple limiters are available. + +The `TIME_DISCRE_SPECIES` can be either an implicit or explicit euler and a CFL reduction coefficient `CFL_REDUCTION_SPECIES` compared to the regular `CFL_NUMBER` is available. + +The inital species mass fractions are given by the list `SPECIES_INIT= 1.0, ...`. + +`SPECIES_CLIPPING= YES` with the respective lists for min and max enforces a strict lower and upper limit for the mass fraction solution used by the solver. + +``` +% --------------------- SPECIES TRANSPORT SIMULATION --------------------------% +% +% Specify scalar transport model (NONE, PASSIVE_SCALAR) +KIND_SCALAR_MODEL= NONE +% +% Mass diffusivity model (CONSTANT_DIFFUSIVITY) +DIFFUSIVITY_MODEL= CONSTANT_DIFFUSIVITY +% +% Mass diffusivity if DIFFUSIVITY_MODEL= CONSTANT_DIFFUSIVITY is chosen. D_air ~= 0.001 +DIFFUSIVITY_CONSTANT= 0.001 +% +% Turbulent Schmidt number of mass diffusion +SCHMIDT_NUMBER_TURBULENT= 0.7 +% +% Inlet Species boundary marker(s) with the following format: +% (inlet_marker, Species1, Species2, ..., SpeciesN-1, inlet_marker2, Species1, Species2, ...) +MARKER_INLET_SPECIES= (inlet, 0.5, ..., inlet2, 0.6, ...) +% +% Use strong inlet and outlet BC in the species solver +SPECIES_USE_STRONG_BC= NO +% +% Convective numerical method for species transport (SCALAR_UPWIND) +CONV_NUM_METHOD_SPECIES= SCALAR_UPWIND +% +% Monotonic Upwind Scheme for Conservation Laws (TVD) in the species equations. +% Required for 2nd order upwind schemes (NO, YES) +MUSCL_SPECIES= NO +% +% Slope limiter for species equations (NONE, VENKATAKRISHNAN, VENKATAKRISHNAN_WANG, BARTH_JESPERSEN, VAN_ALBADA_EDGE) +SLOPE_LIMITER_SPECIES = NONE +% +% Time discretization for species equations (EULER_IMPLICIT, EULER_EXPLICIT) +TIME_DISCRE_SPECIES= EULER_IMPLICIT +% +% Reduction factor of the CFL coefficient in the species problem +CFL_REDUCTION_SPECIES= 1.0 +% +% Initial values for scalar transport +SPECIES_INIT= 1.0, ... +% +% Activate clipping for scalar transport equations +SPECIES_CLIPPING= NO +% +% Maximum values for scalar clipping +SPECIES_CLIPPING_MAX= 1.0, ... +% +% Minimum values for scalar clipping +SPECIES_CLIPPING_MIN= 0.0, ... +``` + +For the screen, history and volume output multiple straight forward options were included. Whenever a number is used at the end of the keyword, one for each species (starting at zero) can be added. +``` +SCREEN_OUTPUT= RMS_SPECIES_0, ..., MAX_SPECIES_0, ..., BGS_SPECIES_0, ..., \ + LINSOL_ITER_SPECIES, LINSOL_RESIDUAL_SPECIES, \ + SURFACE_SPECIES_0, ..., SURFACE_SPECIES_VARIANCE +``` + +For `HISTORY_OUTPUT` the residuals are included in `RMS_RES` and the linear solver quantities in `LINSOL`. The surface outputs can be included with `SPECIES_COEFF` or `SPECIES_COEFF_SURF` for each surface individually. + +For `VOLUME_OUTPUT` no extra output field has the be set. The mass fractions are included in `SOLUTION` and the volume residuals in `RESIDUAL`. + +All available output can be printed to screen using the `dry-run` feature of SU2: +``` +$ SU2_CFD -d .cfg +``` + +## Running SU2 + +The simulation can be run in serial using the following command: +``` +$ SU2_CFD species3_primitiveVenturi.cfg +``` +or in parallel with your preferred number of cores (for this small case not more than 4 cores should be used): +``` +$ mpirun -n <#cores> SU2_CFD species3_primitiveVenturi.cfg +``` + +## Results + +The case converges nicely as expected on such a simple case and mesh. + +![Residual plot](../../tutorials_files/incompressible_flow/Inc_Species_Transport/images/residuals_specMix.png) +Figure (2): Residual plot (Incompressible mean flow, SST turbulence model, species transport). + +Note that there is still some unphysical mass fraction fluctuation for Species_0 at the junction corner. This becomes much less apparent by using `MUSCL_SPECIES = YES` but does not fully disappear. + +![Species Mass Fractions](../../tutorials_files/incompressible_flow/Inc_Species_Transport/images/speciesMassFractions.jpg) +Figure (3): Volume mass fractions for both species. Species_1 is mirrored for better comparison. + +Velocity magnitude field along which the species are transported. For a much less homogenous mixture at the outlet one could decrease the `DIFFUSIVITY_CONSTANT` which makes for a more interesting optimization problem. + +![Velocity Magnitude](../../tutorials_files/incompressible_flow/Inc_Species_Transport/images/VelocityMag.jpg) +Figure (4): Velocity Magnitude in the domain. + +## Additional remarks + +An in depth optimization of this case with addition of the FFD-box, gradient validation and some more steps can found [here](/tutorials/Species_Transport/). \ No newline at end of file diff --git a/_tutorials/index.md b/_tutorials/index.md index 51fff3bf..97c05658 100644 --- a/_tutorials/index.md +++ b/_tutorials/index.md @@ -56,7 +56,7 @@ A simulation of internal, inviscid, incompressible flow around a NACA 0012 hydro * [Laminar Flat Plate with Heat Transfer](/tutorials/Inc_Laminar_Flat_Plate/) Simulation of external, laminar, incompressible flow over a flat plate (classical Navier-Stokes case). * [Turbulent Flat Plate](/tutorials/Inc_Turbulent_Flat_Plate/) -Simulation of external, turbulentm incompressible flow over a flat plate (classical RANS case). +Simulation of external, turbulent incompressible flow over a flat plate (classical RANS case). * [Turbulent NACA 0012](/tutorials/Inc_Turbulent_NACA0012/) Simulation of external, viscous, incompressible flow around the NACA 0012 using a turbulence model. * [Laminar Backward-facing Step](/tutorials/Inc_Laminar_Step/) @@ -65,6 +65,8 @@ Simulation of internal, laminar, incompressible flow over a backward-facing step Simulation of internal, laminar, incompressible flow in a differentially-heated cavity under the influence of gravity (classical natural convection case). * [Streamwise Periodicity](/tutorials/Inc_Streamwise_Periodic/) Simulation of internal, turbulent, incompressible flow in a unit cell of a 2D pin-fin heat exchanger. +* [Species Transport](/tutorials/Inc_Species_Transport/) +Simulation of internal, turbulent, incompressible flow through a mixing channel. #### Structural Mechanics @@ -97,6 +99,8 @@ Perform an optimal shape design of a 2D geometry (isolated airfoil at turbulent * [Constrained shape design of a transonic inviscid wing at a cte. CL](/tutorials/Inviscid_3D_Constrained_ONERAM6/) Learn the basis of 3D design by performing an optimal shape design of an isolated wing with geometrical constraints. * [Multi-Objective Shape Design of an Inviscid Supersonic Ramp](/tutorials/Multi_Objective_Shape_Design/) - Perform an optimal shape design with multiple objectives and a penalty function +Perform an optimal shape design with multiple objectives and a penalty function * [Unsteady Shape Optimization](/tutorials/Unsteady_Shape_Opt_NACA0012/) - Shape optimization of an 2D airfoil in unsteady flow conditions. +Shape optimization of an 2D airfoil in unsteady flow conditions. +* [Species Transport](/tutorials/Species_Transport/) +Optimization of internal, turbulent, incompressible flow through a mixing channel. diff --git a/tutorials_files/design_features/Species_Transport/images/FFD-Box-indicators.jpg b/tutorials_files/design_features/Species_Transport/images/FFD-Box-indicators.jpg new file mode 100644 index 00000000..c27903da Binary files /dev/null and b/tutorials_files/design_features/Species_Transport/images/FFD-Box-indicators.jpg differ diff --git a/tutorials_files/design_features/Species_Transport/images/FFD-Box.jpg b/tutorials_files/design_features/Species_Transport/images/FFD-Box.jpg new file mode 100644 index 00000000..0e0e4f5d Binary files /dev/null and b/tutorials_files/design_features/Species_Transport/images/FFD-Box.jpg differ diff --git a/tutorials_files/design_features/Species_Transport/images/OF_GradNorm.png b/tutorials_files/design_features/Species_Transport/images/OF_GradNorm.png new file mode 100644 index 00000000..e80a33be Binary files /dev/null and b/tutorials_files/design_features/Species_Transport/images/OF_GradNorm.png differ diff --git a/tutorials_files/design_features/Species_Transport/images/Optimized-Geometry.jpg b/tutorials_files/design_features/Species_Transport/images/Optimized-Geometry.jpg new file mode 100644 index 00000000..6236c48e Binary files /dev/null and b/tutorials_files/design_features/Species_Transport/images/Optimized-Geometry.jpg differ diff --git a/tutorials_files/design_features/Species_Transport/images/bad-mesh-deform.jpg b/tutorials_files/design_features/Species_Transport/images/bad-mesh-deform.jpg new file mode 100644 index 00000000..e8452752 Binary files /dev/null and b/tutorials_files/design_features/Species_Transport/images/bad-mesh-deform.jpg differ diff --git a/tutorials_files/design_features/Species_Transport/images/good-mesh-deform.jpg b/tutorials_files/design_features/Species_Transport/images/good-mesh-deform.jpg new file mode 100644 index 00000000..b0667430 Binary files /dev/null and b/tutorials_files/design_features/Species_Transport/images/good-mesh-deform.jpg differ diff --git a/tutorials_files/design_features/Species_Transport/images/opt_cycle.gif b/tutorials_files/design_features/Species_Transport/images/opt_cycle.gif new file mode 100644 index 00000000..e27d966e Binary files /dev/null and b/tutorials_files/design_features/Species_Transport/images/opt_cycle.gif differ diff --git a/tutorials_files/incompressible_flow/Inc_Species_Transport/images/VelocityMag.jpg b/tutorials_files/incompressible_flow/Inc_Species_Transport/images/VelocityMag.jpg new file mode 100644 index 00000000..e73c21f6 Binary files /dev/null and b/tutorials_files/incompressible_flow/Inc_Species_Transport/images/VelocityMag.jpg differ diff --git a/tutorials_files/incompressible_flow/Inc_Species_Transport/images/mesh.jpg b/tutorials_files/incompressible_flow/Inc_Species_Transport/images/mesh.jpg new file mode 100644 index 00000000..6e9d8f6a Binary files /dev/null and b/tutorials_files/incompressible_flow/Inc_Species_Transport/images/mesh.jpg differ diff --git a/tutorials_files/incompressible_flow/Inc_Species_Transport/images/residuals_specMix.png b/tutorials_files/incompressible_flow/Inc_Species_Transport/images/residuals_specMix.png new file mode 100644 index 00000000..6ddf41eb Binary files /dev/null and b/tutorials_files/incompressible_flow/Inc_Species_Transport/images/residuals_specMix.png differ diff --git a/tutorials_files/incompressible_flow/Inc_Species_Transport/images/speciesMassFractions.jpg b/tutorials_files/incompressible_flow/Inc_Species_Transport/images/speciesMassFractions.jpg new file mode 100644 index 00000000..f9826574 Binary files /dev/null and b/tutorials_files/incompressible_flow/Inc_Species_Transport/images/speciesMassFractions.jpg differ