[WillemFloris]

Hi!


Currently I am optimizing 2D airfoil models for my master thesis. I did a small test with a naca0012 at AOA of 0 degree (Re = 0.7e6) just to check whether the optimization process works for this incompressible case.
I changed the objective function to drag, without any constraints. I aspected the optimizer to deform the airfoil shape untill a flat plate is reached, but this is not the case. It creates approximately 14 designs and after the 14th design, it starts over and it calculates the first design again. Furthermore the 14th design was just a small adjustment on the 1st design.
I am wondering whether there is an inbuild constraint in the code, which prevents the code to flatten out the airfoil totally.


Kind regards,


Floris

[hlk]

Originally Posted by WillemFloris

Hi!


Currently I am optimizing 2D airfoil models for my master thesis. I did a small test with a naca0012 at AOA of 0 degree (Re = 0.7e6) just to check whether the optimization process works for this incompressible case.
I changed the objective function to drag, without any constraints. I aspected the optimizer to deform the airfoil shape untill a flat plate is reached, but this is not the case. It creates approximately 14 designs and after the 14th design, it starts over and it calculates the first design again. Furthermore the 14th design was just a small adjustment on the 1st design.
I am wondering whether there is an inbuild constraint in the code, which prevents the code to flatten out the airfoil totally.


Kind regards,


Floris

It sounds like the optimizer failed to improve the objective and returned to the initial point for that reason - possibly due to an inaccurate gradient. Some of the test cases are set up with a low number of iterations for testing purposes, but more convergence is needed in a real case.

A thickness constraint can be applied. The type of design variables and the upper and lower bounds will also effect the results.

[WillemFloris]

Hi Heather,

I would like to thank you for your quick response. I checked the convergence and indeed more convergence is needed.

Kind regards,

Floris van der Schuur

[WillemFloris]

Hi Heather,

If we consider the first design step (DNS001), the optimization program first calculate the direct solution. Then a new geometry has been created in the geometry folder and afterwards the sensitivities of the objective function to the new geometry are calculated. The number of iterations of the last step (calculating the sensitivities of the objective function to the new geometry) is the same as the number of calculations in the .cfg file. Is there a way to change the number of iterations of the last step?

If log_adjoint.out has been examined, there are 6 columns; Iter, Time, Res[Psi_Press], Res[Psi_Velx], Sens_Geo, Sens_Mach. I am wondering in what sense Res[pressure] differs from Res[Psi_Press]. What does Psi indicate? Furthermore, how can I know that the number of iterations are enough? For example Res[Psi_Press]= e-4.3 Res[Psi_Velx]=e-4.3 Sens_Geo=1736.9, is that enough to be sure for a good result, or should the Residuals be even lower?

And if the overall log.txt (the file which is located in the same directory as the .cfg file) has been examined. There are four columns: NIT, FC, OBJFUN, GNORM. I think this means: number of iterations, number of function constraints, objective function and the GNORM. Is this correct? I assume GNORM is a kind of L-norm? Is that also correct?

I look forward to your reply. Many thanks in advance!

[hlk]

Originally Posted by WillemFloris

Hi Heather,

If we consider the first design step (DNS001), the optimization program first calculate the direct solution. Then a new geometry has been created in the geometry folder and afterwards the sensitivities of the objective function to the new geometry are calculated. The number of iterations of the last step (calculating the sensitivities of the objective function to the new geometry) is the same as the number of calculations in the .cfg file. Is there a way to change the number of iterations of the last step?

If log_adjoint.out has been examined, there are 6 columns; Iter, Time, Res[Psi_Press], Res[Psi_Velx], Sens_Geo, Sens_Mach. I am wondering in what sense Res[pressure] differs from Res[Psi_Press]. What does Psi indicate? Furthermore, how can I know that the number of iterations are enough? For example Res[Psi_Press]= e-4.3 Res[Psi_Velx]=e-4.3 Sens_Geo=1736.9, is that enough to be sure for a good result, or should the Residuals be even lower?

And if the overall log.txt (the file which is located in the same directory as the .cfg file) has been examined. There are four columns: NIT, FC, OBJFUN, GNORM. I think this means: number of iterations, number of function constraints, objective function and the GNORM. Is this correct? I assume GNORM is a kind of L-norm? Is that also correct?

I look forward to your reply. Many thanks in advance!

'Psi' indicates the adjoint (aka, co-state, lagrange-multiplier, dual) variable. These are the variables that the adjoint problem is solving for, in a very similar way to how the flow variables are solved for in the direct (flow) problem.
In terms of how far it is converged, you should look at both the residual values and whether the sens_geo value is constant. If you want to have the automatic convergence check look at whether sens_geo is nearly constant, use the CAUCHY convergence criteria (and adjust the cauchy tolerance to your preference).
Sometimes it is harder to get the adjoint problem to reduce the residual by six orders of magnitude, which is our normal suggestion for how far to reduce the residual in the direct (flow) problem.

Is the log.txt file just the redirected output from the shape_optimization script? Otherwise this may be coming directly from the python optimizer. You are mostly correct about the meaning of the columns - 'FC' refers to 'function calls'. Often during optimization line searches are needed between major iterations of the optimizer. This will produce additional 'DSN_*' subdirectories, and the NIT output will help identify which of the DSN's are the major iterations.

[WillemFloris]

Hello Heather,

First I would like to thank you again for your explanation!
I have been trying to get an optimized shape out of the FFA-3W-241 airfoil, this is without succes. I would like to give you more information about this problem:

The first & second deformed design (DSN_002 & DSN_003) differs from the initial design, however the shape of DSN_004->DSN_012 are approximately the same as the initial design. In order to find the cause of the problem, I examined the output files. I checked the config_SOL.cfg and the DV_VALUE_NEW and OLD are the same. Is this correct?

Below I put my in/output files, so you can have a look at the .cfg file and output files. I hope it clarifies a lot

input files: Input_files.zip

DSN_002_DIRECT : DSN_002_DIRECT.zip
DSN_002_DEFORM: DSN_002_DEFORM.zip

DSN_007_DIRECT: DSN_007_DIRECT.zip
DSN_007_DEFORM: DSN_007_DEFORM.zip

I hope you can help me solving this problem. I appreciate your help! Many thanks in advance.

Kind regards,

Floris

[S.Kontogiannis]

Hello,

I cannot open your grid to see your initial and deformed designs. If you could post a dat version or even pictures showing your designs and the mesh, it might be more helpful.

Building on hlk's response, regarding your question on why the airfoil does not converge to a flat plate, apart from adjoint convergence issues and all things that hlk mentioned, I would like to suggest:

If I am not mistaken, from what I see in your .cfg you have a non-finite angle of attack which might lead to a slight camber on the optimised design anyway, depending on your other operating conditions as well.

Also, I see that you are using FFD. Note that FFD is not a method of parameterizing the airfoil, but a way of parameterizing its deformation. Again, depending on your design variables (control points) bounds a flat plate might not even be able to occur. The bounds might not be big enough to allow your (I guess cambered?) airfoil to reach a thin non cambered thin plate.

I hope this might help a bit.

Spyros

[WillemFloris]

Hello Spyros,

I would like to thank you for your time and interest. I really don't know why the shape is deforming to the initial shape, any help is appreciated.
I put two figures in the appendix, one for the first optimized shape and one for the 6th optimized shape. For both red indicates the new shape, white indicates the initial shape. For the 6th design the white design is on top of the red design, this means the shape deformed back to the initial shape.

First optimized design: 1st_optimized_shape.jpg

6th optimized design:6th_optimized_shape.jpg

Many thanks in advance and I hope you have an idea about the cause of this problem

Kind regards,

Floris van der Schuur

[S.Kontogiannis]

Hi WillemFloris,

Well, with this initial airfoil shape, I don't think you should expect to come up with a flat plate in the end. Even with very wide control point bounds, the presence of the positive angle of attack will probably steer the optimizer into a thin flatplate-like design with a slight reflex near the TE.

As for the fact that it returns to the initial shape: although it is not my field, i would also go with what hlk already said. It may be an issue from insufficient adjoint solution convergence. The changes of the design vectors from what i see from you pictures, are very local anyway. So maybe, the accuracy of the adjoint solution is not enough to provide reliable numerical solutions for the operations involved in getting a design direction and a reliable line search. I might be mistaken though since as I said this is not field. Have you tried reaching the developers of SU2?

Spyros

[WillemFloris]

Hello Spyros,

Many thanks for your reply! Thank you for your help and time.

Yes it is true that the shape won't go to a flat plate shape, especially when the angle of attack of 3 degrees is taken into account.

Regarding the shape deformation (returning to initial shape), according to you and hlk, this behavior is due to the convergence of the adjoint solution. However I don't have much experience in a convergence of an adjoint solution. Maybe you can help me with indicating whether the adjoint solution is converged (I used cauchy convergence criteria applies on "Sens_geo" . The adjoint solution files are (note: only the last 5000 iterations of the history file are listed):
of_grad_cd.xlsx
surface_adjoint.xlsx
history_adjoint.csv.zip

Don't you think it is due to the line search process? Because the airfoil is deformating back to the orginal shape during the line search process...

The changes are indeed local, this is due to the line searches right? Or do you mean, that the changes are even for line searches very local. I tried some adjustments to the accuracy before, (1e-8 -> 1e-6-> 1e-2), however the same behavior appears.

I have a question regarding to the optimization process. In every SU2 optimization document the optimization proces is explained by: first geometry is deformed, then the mesh is deformed, subsequently the analysis and sensitivity analysis takes place. This last item, sensitivity analysis, is the adjoint process right? But the geometry and grid are not deformed yet. How can the adjoint process continue without a deformed shape? Indeed there are deformed shapes created in a file located in the same directory as the .cfg directory, however these deformed shapes are the same as the initial shape...

Again many thanks Spyros! I would appriciate you to have a look in the files .

Kind regards,

Floris

[beatlejuice]

Hey Floris,

I had problems with the optimization of a 2D airfoil (incompress.), too.
For me it worked out to switch to the compressible solver and use the discrete adjoint instead of the continuous adjoint!

cheers