<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Hi Matt,<br>
<br>
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
<br>
<br>
      gen_rea(2)<br>
<br>
from usrdat2() which outpost the mesh and BC portion of .rea file in newrea.out<br>
<br>
Aleks<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF414116"><font size="2" color="#000000" face="Tahoma"><b>From:</b> nek5000-users-bounces@lists.mcs.anl.gov [nek5000-users-bounces@lists.mcs.anl.gov] on behalf of nek5000-users@lists.mcs.anl.gov [nek5000-users@lists.mcs.anl.gov]<br>
<b>Sent:</b> Monday, May 05, 2014 2:32 AM<br>
<b>To:</b> nek5000-users@lists.mcs.anl.gov<br>
<b>Subject:</b> Re: [Nek5000-users] Rules of thumb for element aspect ratio limits<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">
<div>Hi Florian,<br>
<br>
</div>
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.
<br>
<br>
Matt<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sun, May 4, 2014 at 12:23 PM, <span dir="ltr"><<a href="mailto:nek5000-users@lists.mcs.anl.gov" target="_blank">nek5000-users@lists.mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div bgcolor="#FFFFFF">Hi Matt,<br>
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?<br>
<br>
Florian<br>
<br>
<div>Am 28.04.2014 12:16, schrieb <a href="mailto:nek5000-users@lists.mcs.anl.gov" target="_blank">
nek5000-users@lists.mcs.anl.gov</a>:<br>
</div>
<div>
<div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Hi Wei and Florian,<br>
<br>
</div>
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.
<br>
<br>
</div>
For DNS of the boundary layer region close to the wing you generally want <br>
dx+~10<br>
</div>
dy+ ~ 0.5 next to the wall, less than dz+ away from the wall<br>
</div>
dz+ ~ dx+/2<br>
<br>
</div>
<div>This gives a maximum aspect ratio of about 20 near the wall (dx/dz). <br>
</div>
<div><br>
</div>
In the wake / separated flow region you generally want max(dx,dy,dz)/eta < 4 where eta is the kolmogorov lengthscale.
<br>
<br>
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.<br>
<br>
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
<br>
dx < dy < dz<br>
dx < dz < dy,  <br>
dy < dx < dz<br>
dy < dz < dx<br>
dz < dx < dy<br>
dz < dy < dx<br>
<br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
For generating the mesh itself.<br>
</div>
We have an inhouse generated method based on gridgen-c. <a href="https://code.google.com/p/gridgen-c/" target="_blank">
https://code.google.com/p/gridgen-c/</a> . 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.
<br>
<br>
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.
<br>
<br>
Matt<br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Apr 25, 2014 at 10:17 PM, <span dir="ltr"><<a href="mailto:nek5000-users@lists.mcs.anl.gov" target="_blank">nek5000-users@lists.mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir="auto">
<div>Hi matt,</div>
<div>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. </div>
<div>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? </div>
<div>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?</div>
<div><br>
</div>
<div>Florian</div>
<div><br>
Am 25.04.2014 um 18:02 schrieb <a href="mailto:nek5000-users@lists.mcs.anl.gov" target="_blank">
nek5000-users@lists.mcs.anl.gov</a>:<br>
<br>
</div>
<div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">·HI Matt,
<div><br>
</div>
<div>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!</div>
<div><br>
</div>
<div>Wei<br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-04-25 17:00 GMT+02:00 <span dir="ltr"><<a href="mailto:nek5000-users@lists.mcs.anl.gov" target="_blank">nek5000-users@lists.mcs.anl.gov</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>Hello,<br>
<br>
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. <br>
<br>
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?<br>
<br>
</div>
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.
<br>
</div>
1. limit the maximum aspect ratio to a critical value<br>
</div>
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.
<br>
<br>
</div>
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?<br>
<br>
Thanks,<br>
<br>
Matt<br>
</div>
<br>
_______________________________________________<br>
Nek5000-users mailing list<br>
<a href="mailto:Nek5000-users@lists.mcs.anl.gov" target="_blank">Nek5000-users@lists.mcs.anl.gov</a><br>
<a href="https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users</a><br>
<br>
</blockquote>
</div>
<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>Nek5000-users mailing list</span><br>
<span><a href="mailto:Nek5000-users@lists.mcs.anl.gov" target="_blank">Nek5000-users@lists.mcs.anl.gov</a></span><br>
<span><a href="https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users</a></span><br>
</div>
</blockquote>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Nek5000-users mailing list<br>
<a href="mailto:Nek5000-users@lists.mcs.anl.gov" target="_blank">Nek5000-users@lists.mcs.anl.gov</a><br>
<a href="https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset target="_blank"></fieldset> <br>
<pre>_______________________________________________
Nek5000-users mailing list
<a href="mailto:Nek5000-users@lists.mcs.anl.gov" target="_blank">Nek5000-users@lists.mcs.anl.gov</a>
<a href="https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users</a>
</pre>
</blockquote>
<br>
</div>
</div>
<div class="">
<pre cols="72">-- 
-----------------------------------------------------------------------------
Dipl. Ing. Florian Hindenlang
Institut fuer Aerodynamik und Gasdynamik 
Phone: 0049 (0)711-685 63413
office 1.14
Pfaffenwaldring 21
70569 Stuttgart 
E-Mail: <a href="mailto:hindenlang@iag.uni-stuttgart.de" target="_blank">hindenlang@iag.uni-stuttgart.de</a>
---------------------------------------------------------------------------
</pre>
</div>
</div>
<br>
_______________________________________________<br>
Nek5000-users mailing list<br>
<a href="mailto:Nek5000-users@lists.mcs.anl.gov" target="_blank">Nek5000-users@lists.mcs.anl.gov</a><br>
<a href="https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>