SU2_DEF and SU2_DOT_AD not computing results for centrifugal turbomachinery flow scenario

LorenzoFabris commented 1 year ago

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):

Screenshot (157)

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

Screenshot (158)

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_RELAXFACTOR 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

pcarruscag commented 1 year ago

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.

LorenzoFabris commented 1 year ago

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.

pcarruscag commented 1 year ago

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)

LorenzoFabris commented 1 year ago

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?

pcarruscag commented 1 year ago

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.

pcarruscag commented 1 year ago

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

LorenzoFabris commented 1 year ago

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 FFDDEFINITION). 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.

pcarruscag commented 1 year ago

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.

LorenzoFabris commented 1 year ago

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):

Screenshot (162)

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).

pcarruscag commented 1 year ago

It's the other right hand rule where you wrap the fingers around a vector

pcarruscag commented 1 year ago

The fix is in develop, thank you for reporting

su2code / SU2