[Nek5000-users] Rules of thumb for element aspect ratio limits
nek5000-users at lists.mcs.anl.gov
nek5000-users at lists.mcs.anl.gov
Mon May 5 02:32:09 CDT 2014
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> 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:
>
> 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> 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:
>>
>> ·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>:
>>
>>> 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
>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
>>>
>>>
>>
>> _______________________________________________
>> Nek5000-users mailing list
>> 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
>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
>>
>>
>
>
> _______________________________________________
> Nek5000-users mailing listNek5000-users at lists.mcs.anl.govhttps://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
> ---------------------------------------------------------------------------
>
>
> _______________________________________________
> Nek5000-users mailing list
> 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/20140505/b5d24f87/attachment.html>
More information about the Nek5000-users
mailing list