Problem with dynamic mesh (EXTERNAL - 3D)
 

Hi everyone,

I’m currently trying to simulate a pitching airfoil attached to a fixed body. As SU2 does not support non-conformal interfaces, the only option available within the existing SU2 code is to use the external kind of grid movement (can't use rigid motion, rotating frames or moving walls).

Unfortunately, I’m having trouble with the external mesh motion type, especially in 3D: the mesh smoother keeps diverging (?), even with very small changes in the pitch angle (0.05 degrees crashes the solver). I actually get negative volume cells even if my original grid does not contain any. The grid currently used is viscous and is built to have a y+ value of 1. Wall cell height is therefore small (2.5e-6 m).

Prior to running these 3D cases, I tested SU2 features in 2D. While testing, I have found weird grid solver behavior when running parallel 2D test cases. In fact, the volume grid solver requires more linear iterations as the number of partitions is increased, as seen in the table below. The number of cells for the 2D case is 47600.

Following the idea that more partitions seems to destabilize the volume grid solver, I tried to reduce the number of partitions I used for another 3D test case (257 400 cells) and it actually stopped crashing when I used 4 partitions or less. This is good news, however impractical as running 3D cases on 4 partitions requires quite a bit of time.

I had a look in the code, but couldn’t find anything.

Does anyone have any idea of what’s happening? Has anyone else encountered such problem?

I'll check if I can reproduce the problem with a grid in the TestCases folder with a new configuration file and update accordingly.

Regards,
Frederik

Update...
 

Hello everyone,

I was able to continue my investigations on the dynamic mesh external errors I’ve encountered so far. Also sorry about the length of this post...

The problem seems to happen when the following conditions are all met:

• 3D grid
• External mesh motion specified (GRID_MOVEMENT_KIND=EXTERNAL)
• Large number of partitions used (parallel)
• Large aspect ratio cells such as boundary layers cells (new)
• Used SU2 3.2.7, as 3.2.8 was not yet available when I started the tests.

Here is my test case details, as the bug is not easily demonstrable using the grids included in the TestCases suite. In fact, grids with boundary layers crash instantly and unstructured grids work fine.

• 3D grid.
• 0.5 x 0.5 x0.05 m flat plate.
• Fully structured (volume extruded from wall surfaces)
• 4 Subgrids, see table below (DS=wall spacing, AR=max aspect ratio, VR=max volume ratio).
• All grids were created by extruding the flat plate surface until it reached a distance of 0.25m. The outer boundary was then set to be the farfield.
• Images of the test case:
  https://qdxhya.by3301.livefilestore....cut.png?psid=1
  https://qtxeya.by3301.livefilestore....ain.png?psid=1

Grid properties:
Test results:
Required time to complete the simulations in seconds (1 fluid iteration per time step). Higher required times are tied to the presence of negative volumes.
I have also included images of the test results. There are 7 images showing 1, 2, 4, 8, 16, 32 and 64 partitions used, along with what the grid looks like after some iterations.
https://qtxfya.by3301.livefilestore....art.png?psid=1
https://qtxeya.by3301.livefilestore....art.png?psid=1
https://qtxeya.by3301.livefilestore....art.png?psid=1
https://qtxeya.by3301.livefilestore....art.png?psid=1
https://qtxeya.by3301.livefilestore....art.png?psid=1
https://qtxeya.by3301.livefilestore....art.png?psid=1
https://qtxeya.by3301.livefilestore....art.png?psid=1

...continued...

Update #2...
 

...continued...

Some observations too:

• 2D high aspect ratio grids don't seem to pose problem.
• The number of partitions is not a condition by itself; it feels more like a contributing factor: the more partitions are used, the more likely negative volume cells will appear.
• I have also verified that creating a grid in millimeter or meter didn’t change the outcome (which could relate to an accuracy problem in either the grid or the SU2 grid reader).
• I’m currently using Pointwise's TRex grids. I have verified that these grids show the problem too, as long as they have high aspect ratios in the boundary layers.
• I'm not using grids with dimensions close to the eps value.
• As stated in this post (http://www.cfd-online.com/Forums/su2...ities-su2.html), I have also experienced problems with symmetry boundaries and external grid motion.
• Grid motion amplitude does play a small role, but I have not tested more thoroughly. I was able to get rid of the negative volume cells with the high aspect ratio case and 4 partitions when rotating the flat plate by only 0.05 degrees per time step. The other cases were able to achieve 15 degrees per time step without problems.
• I have tested the number of linear and non-linear iterations. They do not appear to help versus negative volumes.
• I have played with the deform_tol_factor option with little to no impact on the creation of negative volume cells. I was only able to very slightly delay them.
• I have tried to make use of the hold_grid_fixed option with coordinates, as described in the code itself (I didn’t find mention of it in any of the config templates/documentation). It did help, but negative volume cells still appeared.
• I have tried to increase the domain size to divide the flat plate cell deformations into more cells, but didn’t help.
• I have also found a bug with the EXTERNAL_ROTATION dynamic mesh option that does not rescale the ROTATION_RATE_X/Y/Z if the reference values definition are not set to 1.0. You have to use references of 1.0 everywhere, else it will rescale it as if it was non-dimensional.
• It seems the problem is located in the cell boundaries that are normal to walls, as illustrated in this image:
  https://qtxeya.by3301.livefilestore....oom.png?psid=1

Additionally, I had initially investigated 2D tests on high aspect ratio cells (impact of linear and non-linear interactions and solver) with the following results. There is no problem here per se, it could just be useful for other people.
https://qtxeya.by3301.livefilestore....ess.png?psid=1
https://qtxeya.by3301.livefilestore....ume.png?psid=1
https://qtxeya.by3301.livefilestore....nce.png?psid=1

Hi Frederik,

Thank you for sharing your experience here. I just have some questions regarding your problem. From your post I understood you are using external grid solver in your process, right? If so could you please provide more information on your grid procedure.

Are you remeshing the entire domain in every time step or updating your mesh? Besides, I think it is possible to create a series of mesh that is marched in time and mapping the solution between them in a simulation like yours.

Is there a gap in your geometry between the pitching airfoil and the solid body? You may consider using FFD box to deform your pitching airfoil for simulating its movement.

I haven't used this feature of SU2 yet, but more information on your dynamic mesh process including how you are linking your external grid solver and how you are updating the mesh will help.

Bests,
Payam

Thanks for the reply. I'm not currently at home and my images are not showing... can you see the images?

I'm using this:
When using the EXTERNAL keyword, SU2 reads a boundary mesh file (the boundary surfaces) and updates (moves) them every time step. SU2 deforms the interior mesh.

To create my grid, I used Pointwise. Then I exported the grid in a SU2 format. I used some Matlab tools (included in SU2 source in /MeshTools/Matlab/) and made some of my own. I simply read the grid file, recorded what nodes are located in the surface boundaries and deplaced them.

I'm not remeshing the entire domain, I'm deforming it. I update the mesh every time step by moving the boundaries. SU2 deforms the interior volumes.

Regards,
Frédérik

Yeah, sure I am seeing the pictures. They are good.

Thank you for the explanation. I think SU2 is updating (here I mean remeshing) your entire domain in every time step. That's way it is crashing sometimes like a meshy explosion. However, it is reasonable to know the developers' opinion here about the remeshing, deforming and updating. Anyway, in case it uses deformation, try to use remeshing instead to see whether the problem persists or not.

If you want to use the deformation, I suggest you to create a FFD box around your pitching component and move that component in every time step. The mesh will deform automatically. The FFD box is used in optimization problems as parametrization technique, but you can trick this technique to move the component instead. There will be no crash like what you have gotten here, except you might confront with negative volume mesh problems, which might be resolved by decreasing the time step size.

Meanwhile, I suggest you to check this thread as well: 2D NACA 6412 Tutorial Extrusion Problem
You will see pictures like yours in which a kind of meshy explosion happened due to use of single precision display rendering.

Additionally, there are other approaches to move that component in a simulation:

1] You can create a series of structured mesh with constant resolution in specific time steps separately, in which your component is moving. Then, for your simulation which is marching in time, map the solution from one to another respectfully. It sometimes called quasi-static approach.

2] You can create a small overset structured block around your component, then define a unstructured interface between the solid body and the moving component. It results a hybrid grid in overall. For the movement, move the component with its overset structured boundary layer block, and just remesh, deform or update the unstructured block alone. This approach maintains the grid quality, and also resolves the meshy-explosion-liked problem.

3] As already mentioned, you can use FFD box around your moving component to simulate its motion. The fully-structured grid will be deformed. Meanwhile, you can combine this approach with the second aforementioned approach. For this purpose, define a FFD box around your moving component with its structured block for simulating the motion.

The zigzag break in radial grid line is because of the implicit and explicit smoothing factors of the normal extrusion. Can you access the normal extrusion factors? If you do so, decrease the implicit factor and increase the explicit factor. The zigzag break will be disappeared. Try this with a simple normal extrusion in Pointwise, you will see how it works.

Meanwhile, developer's guide here will help you to find out how one can access these factors in the grid module.

These are my suggestions for your case. I hope they help you.

Good Luck,
Payam

As l understand from grid_movement_structure.cpp source code motion_filename should include global vertex index, x-location, y-location for boundary nodes at each time step. However, when l run parallel the vertex index from the solution file is different compared to that of *.su2 mesh file due to reordering. Therefore, do l need any further modification for parallel run?

Best

Mehmet