SU2_DEF and SU2_DOT_AD not computing results for centrifugal turbomachinery flow scenario
LorenzoFabris opened this issue · 11 comments
BUG DESCRIPTION
Flow scenario
The following 3D-centrifugal impeller was designed and the flow field simulated. The aim was to optimize the blade leading edge with respect to outlet static pressure (please note that the mesh is rotating):
The mesh is deliberately coarse being the intention to firstly perform the simulation utilizing Euler's convective scheme.
Subsequently, the flow field is computed correctly and the solution is converged. The solution was obtained setting up the turbomachinery simulation options available in SU2.
After this initial procedure the FFD Box was successfully generated ( FFD_DEGREE = 2,2,2 ) and attached to the domain as explained in the tutorials ( using SU2_DEF ). The FFD box appears as follows:
FFD box edges: green
FFD box control point: yellow
There is no intersection between FFD edges and periodic boundaries
It was intended to operate each SU2 module manually:
- SU2_DEF -> FFD box generation
- SU2_CFD -> flow field computation
- SU2_CFD_AD -> adjoint solution
- SU2_DOT_AD -> gradient calculation
- SU2_DEF -> shape deformation
Shape deformation test
Before the actual gradients computation it was preferred to perform a deformation test with the presented settings:
% ----------------------- DESIGN VARIABLE PARAMETERS --------------------------%
DV_KIND= 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
DV_MARKER= ( BLADE1 )
%
% Parameters of the shape deformation
% - FFD_CONTROL_POINT ( FFD_BoxTag, i_Ind, j_Ind, k_Ind, x_Disp, y_Disp, z_Disp )
%
DV_PARAM= ( BLADE_BOX, 0, 0, 0, 1.0, 0.0, 0.0 ); ( BLADE_BOX, 0, 1, 0, 0.0, 1.0, 0.0 ); ( BLADE_BOX, 0, 1, 1, 0.0, 1.0, 0.0 ); ( BLADE_BOX, 1, 1, 1, 0.0, 1.0, 0.0 )
%
% New value of the shape deformation
DV_VALUE= 0.02, 0.02, 0.02, 0.02
%
OPT_RELAX_FACTOR = 1.0
Moreover, some surfaces were re-assigned to avoid any plane fixing (that was, intentionally, set as FFD_CONTINUITY = USER _INPUT):
MARKER_SYM = ( HUB, SHROUD, BLADE1, PER1, PER2 )
Results
For any given linear solver deformation and parameter the arbitrary mesh deformation test failed (even after hugely increasing both DV_VALUE and OPT_RELAX_FACTOR to exclude a dimensional issue):
- FGMRES solved by initial guess.
- CONJUGATE_GRADIENT reached the convergency conditions but being MAX DIFF. = 0 no deformation was applied to the mesh.
Similarly, SU2_DOT_AD behaved in the same manner even if adjoint solution was tightly converged. To exclude any non-dependency from the objective function, different options were investigated (DRAG, LIFT, SURFACE_MACH, SURFACE_TOTAL_PRESSURE, ENTROPY_GENERATION) and nothing changed.
Moreover, the vaned diffuser scenario (not visualized in here for simplicity) seems to be affected too, even if very similar to basic flow scenarios (basically, it is just an internal 3D-flow over airfoil case). I thought this behavior could be traced to a bug since my previous mesh deformation always proceeded smoothly (from flow past cylinder to other internal flow scenarios), either with arbitrary or gradient based deformation. However, none of these were investigated with turbomachinery settings, which are necessary for this scenario for two main reasons:
- post processing parameters computed by SU2
- this mesh is part of a turbomachinery multi-block simulation
To reproduce
config.txt -> cfg file
mesh_out.txt -> mesh (FFD box attached)
Thank you in advance for your support and your help which is always appreciated.
Cheers!
Bug report checklist
- [ ✓ ] Consulting the build instructions (https://su2code.github.io/docs_v7/Build-SU2-Linux-MacOS/).
- [ ✓ ] Looking for similar problems on GitHub or CFD-Online (https://www.cfd-online.com/Forums/su2/).
- [ ✓ ] Updating to the newest version of SU2 (either develop, master, or the pre-built executables https://su2code.github.io/download.html).
Desktop (please complete the following information):
- OS: ubuntu 20.04.4
- C++ compiler and version: g++ 9.4.0
- MPI implementation and version: Open MPI 4.1.5
- SU2 Version: v7.5.1
The ffd setting is failing for some reason, there are no surface points mapped to the ffd (last line in the mesh file says 0). I could not figure out why yet.
The ffd setting is failing for some reason, there are no surface points mapped to the ffd (last line in the mesh file says 0). I could not figure out why yet.
Ciao Pedro!
Thank you for your dedication.
The mesh I attached was generated with CFX TurboGrid but I could experience the same issue with other meshes too.
Please, let me know if you need other informations that might help you.
The FFD is defined in a way that makes all points fail the "point inside box" check, we need to improve the user-friendliness of this check, try using this order of the points for ffd setting. Applying the right-hand rule to the first 4 points must point into the center of the FFD
0.0134584, 0.0087787, -0.035265,
0.0108551, 0.00980938, -0.041096,
0.00734385, 0.013199, -0.0388281,
0.0114466, 0.0124845, -0.0326164,
0.0276521, 0.0238333, -0.0393685,
0.0240801, 0.0278683, -0.0456933,
0.0203954, 0.0303584, -0.0422846,
0.0246565, 0.0271419, -0.035573)
The FFD is defined in a way that makes all points fail the "point inside box" check, we need to improve the user-friendliness of this check, try using this order of the points for ffd setting. Applying the right-hand rule to the first 4 points must point into the center of the FFD 0.0134584, 0.0087787, -0.035265, 0.0108551, 0.00980938, -0.041096, 0.00734385, 0.013199, -0.0388281, 0.0114466, 0.0124845, -0.0326164, 0.0276521, 0.0238333, -0.0393685, 0.0240801, 0.0278683, -0.0456933, 0.0203954, 0.0303584, -0.0422846, 0.0246565, 0.0271419, -0.035573)
I checked but it works only for this specific mesh. When I apply the same FFD box generation for the diffuser (following the righy-hand rule), I still obtaind MAX DIFF = 0.
In this tutorial, the FFD box points ordering is counterclockwise and I always performed my optimization with this kind of FFD box. I cannot understand if this behavior is mesh dependent or it just me not understanding the way you ordered your points therefore my impossibility to replicate your FFD attachment is the correct way.
Also, could this issue be the origin of this weird shape deformation?
I don't understand the question very well. The order of the points needs to be according to the VTK hexahedron http://www.princeton.edu/~efeibush/viscourse/vtk.pdf
I can't visualize where you are getting that deformation, but when using an FFD box that does not include the entire design surface you need to be careful with the continuity of the deformation to prevent creating discontinuous steps.
Well, it's the F-FFD week it seems :)
https://www.cfd-online.com/Forums/su2/249879-when-use-su2_def-generate-ffd-box-i-can-not-get-ffd_surface_points.html
I don't understand the question very well. The order of the points needs to be according to the VTK hexahedron http://www.princeton.edu/~efeibush/viscourse/vtk.pdf I can't visualize where you are getting that deformation, but when using an FFD box that does not include the entire design surface you need to be careful with the continuity of the deformation to prevent creating discontinuous steps.
Mmmh I see. It looks like the blade elements are extending beyond the blade surface itself and, therefore, are cut by the FFD box even if the whole geometry appears to be included withing the FFD box domain. I solved the issue by defining an user-defined fixing plane (very cool option, btw). I experienced a similar situation with an internal flow over cylinder, too.
My question was whether this behavior was mesh-dependent or FFD box-dependent. I guess it is reasonable to say that mesh elements extension beyond the body which we're optimizing is causing this, however FFD continuity allows to keep this dummy shape deformation from happening.
Secondly, I had MAX DIFF = 0 because I couldn't understand your correction properly. I had to consider the righ-hand rule third component (thumb) pointing inside the FFD box for each of the surfaces we establish when attaching the FFD box (each of those defined by the points listed in FFD_DEFINITION). Then it worked perfectly.
Still, I don't understand why for some geometries we apply what discussed in the tutorial and here it is the opposite. At least I know what to expect and how to fix it. If you could add an alert message in the next SU2 version, that would be much appreciated.
Well, it's the F-FFD week it seems :) https://www.cfd-online.com/Forums/su2/249879-when-use-su2_def-generate-ffd-box-i-can-not-get-ffd_surface_points.html
It's sunday: is the week ending or starting? ahah I guess we both stopped counting ;)
As always, thank you very much for the time you're spending on our bugs and issues.
The message will look like this:
The FFD box 'BLADE_BOX' is not properly defined. The first 4 points must be listed counter
clockwise, such that applying the right-hand rule results in a vector into the box.
This is according to the VTK hexahedron ordering:
7 +----+ 6
/| /|
4 +----+5|
|3+--|-+ 2
|/ |/
0 +----+ 1
The CCW convention also applies in 2D, where only the bottom face is specified.
The message will look like this:
The FFD box 'BLADE_BOX' is not properly defined. The first 4 points must be listed counter clockwise, such that applying the right-hand rule results in a vector into the box. This is according to the VTK hexahedron ordering: 7 +----+ 6 /| /| 4 +----+5| |3+--|-+ 2 |/ |/ 0 +----+ 1 The CCW convention also applies in 2D, where only the bottom face is specified.
Thank you Pedro.
However, for the diffuser scenario, I set up the FFD Box applying the right-hand rule to both surfaces (point the third component to the inside FFD box volume from each surface):
It worked perfectly and mesh is deforming but it is the opposite for the second sets of points compared to what you've done. I don't know if this can help you.
Feel free to attach the updated version of SU2, I'll be happy to test it (I'm currently running it on Ubuntu).
It's the other right hand rule where you wrap the fingers around a vector
The fix is in develop, thank you for reporting