[Nek5000-users] Rules of thumb for element aspect ratio limits

nek5000-users at lists.mcs.anl.gov nek5000-users at lists.mcs.anl.gov
Wed May 7 10:39:24 CDT 2014


Hi Matt,

Our strategy with getting meshes from MOAB to Nek so far has been to run one case with N=2 (lx1=3) in Pn-Pn and call

      gen_rea(2)

from usrdat2() which outpost the mesh and BC portion of .rea file in newrea.out

Aleks
________________________________
From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov]
Sent: Monday, May 05, 2014 2:32 AM
To: nek5000-users at lists.mcs.anl.gov
Subject: Re: [Nek5000-users] Rules of thumb for element aspect ratio limits

Hi Florian,

Moab does allow you to read meshes made in a variety of formats. We were able to make a mesh in cubit and read it in to nek5000 but we didn't get much further than preliminary tests. I'm not sure how well moab does with the curved mesh format. We never tested that. However there are some limitations with using nek with moab, including that as of now you have to use the PN-PN variant, PN-PN-2 is not supported.

Matt


On Sun, May 4, 2014 at 12:23 PM, <nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov>> wrote:
Hi Matt,
I see that you found a similar approach by manually fixing the GLL points. Do you have experience with the Moab interface in Nek? It seems that the geometry of spectral elements is supported. Then probably, the manual fix in nek could be replaced by  the readin of a curved mesh format via moab. What do you think?

Florian

Am 28.04.2014 12:16, schrieb nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov>:
Hi Wei and Florian,

In general you can first generate a 2D grid for flow past a wing if it is a straight wing (of if you represent the 3 dimensionality by a forcing in the z direction to indicate a fixed sweep angle). This is not optimal though for a larger problem even if you have periodic boundary conditions because your dz spacing will be fixed at a small value by the BL region requirements.

For DNS of the boundary layer region close to the wing you generally want
dx+~10
dy+ ~ 0.5 next to the wall, less than dz+ away from the wall
dz+ ~ dx+/2

This gives a maximum aspect ratio of about 20 near the wall (dx/dz).

In the wake / separated flow region you generally want max(dx,dy,dz)/eta < 4 where eta is the kolmogorov lengthscale.

The problem is that with a wake calculation such as an airofil you generally also want the boundaries to be far away. You can do this by growing dx and dy away from the airfoil. However, you will eventually reach a point where your aspect ratio is 10-1,000 far away from the wing as well since dz is small. The problem with doing this is that when you are far away from the wing then dz will still be very small. With a structured mesh there appears to be no way to fix this issue without a multiblock method. For an unstructured mesh there is a possibility of coarsening more in all 3 directions but this is quite challenging to generate.

Also, it is not as simple as just thinking about the maximum value of (dx,dy,dz) divided by the minimum value of (dx,dy,dz). The relative ratios of dx,dy,dz all matter and with a wake you generally have regions where you have all 6 cases of
dx < dy < dz
dx < dz < dy,
dy < dx < dz
dy < dz < dx
dz < dx < dy
dz < dy < dx

All these areas create problems for an iterative solver. You can write a more robust / complex solver (such as a semi-coarsening multigrid algorithm) to handle these different aspect ratio regions but then much more work is required per iteration. It is a trade-off between # of iterations required and computing time per iteration.

For generating the mesh itself.
We have an inhouse generated method based on gridgen-c. https://code.google.com/p/gridgen-c/ . It is not ideal but it can be made to work. We also looked into using cubit for unstructured meshes but we are still testing that. With cubit you can either use moab to load in the mesh to nek but then you have some limitations. For both options you can write your own converter as well... we do this for now.

To curve the boundary layer elements we first generate the element locations themselves and then the GLL points are created on straight line segments. We go back in and manually correct the location of the GLL points located closest to the wall using a spline of the wing. Then we solve a laplace equation to smooth out the GLL points in the rest of the domain.

Matt


On Fri, Apr 25, 2014 at 10:17 PM, <nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov>> wrote:
Hi matt,
Sorry that I cannot fully answer your question, I know that at least the smallest edge length  in the mesh is a measure for the stiffness of the full problem, so maybe you should avoid too small element heights in the boundary layer.
However, I also would like to know  how you are generating the airfoil mesh, since the mesh has to be coarser than a standard meshes and the boundary layer elements need to have curved boundaries, no? Which mesh generator you use and how do you convert the mesh to Nek format?
The 3d problem should boil down to a 2d problem, since I assume that you want simulate a small part of the wing with periodic boundary conditions in spanwise direction... But wei, for the 2d mesh, did you resolve the issue to curve the boundary layer elements?

Florian

Am 25.04.2014 um 18:02 schrieb nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov>:

·HI Matt,

Till now I have no experiments on 3D problem, what I am interested in is how you generate the 3D or 2D airfoil mesh for nek5000? I spend 2 weeks in generated a 2d airfoil flow mesh without any good results. would you like tell me some informations? thank you a lot!

Wei


2014-04-25 17:00 GMT+02:00 <nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov>>:
Hello,

I am looking to do simulations of flow past a wing in 3D using nek5000 and I have been thinking more about potential issues with high aspect ratio elements. In general we have very fine resolution near the wing and then as we get further away the wall normal and wall parallel spacing increases. As a first try we will extend the domain in the cross stream direction which will result in small dz values. I know that in general the best performance is obtained with elements having dx=dy=dz and that as the aspect ratio increases the performance will degrade.

I'm wondering if there are general rules of thumb for the performance degradation with increased aspect ratio. For example, is an aspect ratio of 10 ok but an aspect ratio of 100 unacceptable? Is this even something we can estimate in general or does it vary so much problem to problem that no general estimate is possible?

I saw an earlier post that referred to the paper "An Overlapping Schwarz Method for Spectral Element Solution of the Incompressible Navier-Stokes Equations", P. Fischer JCP 1997. From the paper I see two general strategies.
1. limit the maximum aspect ratio to a critical value
2. design a grid for our case, run it for a short time and then iteratively add more grid points to decrease the aspect ratio until optimal performance is achieved.

Does anyone have a general or specific suggestion regarding how we should handle the grid generation in terms of selecting the largest aspect ratio possible with low computational cost?

Thanks,

Matt

_______________________________________________
Nek5000-users mailing list
Nek5000-users at lists.mcs.anl.gov<mailto:Nek5000-users at lists.mcs.anl.gov>
https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users



_______________________________________________
Nek5000-users mailing list
Nek5000-users at lists.mcs.anl.gov<mailto:Nek5000-users at lists.mcs.anl.gov>
https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users

_______________________________________________
Nek5000-users mailing list
Nek5000-users at lists.mcs.anl.gov<mailto:Nek5000-users at lists.mcs.anl.gov>
https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users





_______________________________________________
Nek5000-users mailing list
Nek5000-users at lists.mcs.anl.gov<mailto:Nek5000-users at lists.mcs.anl.gov>
https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users



--
-----------------------------------------------------------------------------
Dipl. Ing. Florian Hindenlang
Institut fuer Aerodynamik und Gasdynamik
Phone: 0049 (0)711-685 63413
office 1.14
Pfaffenwaldring 21
70569 Stuttgart
E-Mail: hindenlang at iag.uni-stuttgart.de<mailto:hindenlang at iag.uni-stuttgart.de>
---------------------------------------------------------------------------


_______________________________________________
Nek5000-users mailing list
Nek5000-users at lists.mcs.anl.gov<mailto:Nek5000-users at lists.mcs.anl.gov>
https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/nek5000-users/attachments/20140507/f07f7bd8/attachment.html>


More information about the Nek5000-users mailing list