NACA 0012 Airfoil Example

[Zach Davis]

All,

I've posted this enquiry to both Freddie and Peter already, but perhaps others would be able to contribute or be interested in its resolution.  I've made a couple initial attempts to try to setup and run a simulation around a 2D NACA 0012 series airfoil with conditions set at mach = 0.5, aoa = 1 deg, rey = 5000 (ref length = 1ft) at SLS (or tsp = 518.688 deg R).  I've generated a few meshes of varying mesh density.  The latest of which I've shared here is my first attempt at generating a very coarse curvilinear mesh via Gmsh.  After inspecting the initial flow solution, it appears that the fields for pressure, density, and velocity are set according to those prescribed by the boundary conditions.  It appears that the solution diverges very quickly after beginning the run, and I'm trying to better understand why this occurs as I attempt to become more familiar with PyFR and its options.

Best Regards,


Zach Davis

enc

[Vincent, Peter E]

Hi Zach,

Thanks for your interest in PyFR. A few comments:

1.) The initial condition should be set according to:

[soln-ics]

rho = (psp*32.174)/(r*tsp)                  ; Freestream Density (lbm/ft^3)

u = 558.166                                 ; X Component Velocity (ft/s)

v = 9.743                                   ; Y Component Velocity (ft/s)

w = 0.0

p = r*tsp*rey*mu/usp                        ; Freestream Pressure (lbf/ft^2)

from within your .ini file.

2.) The following may be the cause of the solution blowup:

- The mesh is very coarse for a p = 3 run, and hence you are likely dramatically under resolving the flow

- Your time step may be too big, and hence violating the CFL limit (PyFR is explicit in time)

3.) Other comments:

- It may be easier to do everything in non-dimensional form (i.e. chord of 1, inflow speed of 1, free stream density of 1, then set Mach number with the free stream pressure and set the Reynolds number with the viscosity.

- You may want to try using our new characteristic BCs (type=char-riem-inv) for this case (available in v0.2.1). They are not currently documented, but require specification of the full free stream state.

Hope this is of some help. Others may have more detailed comments.

Cheers

Peter

--
You received this message because you are subscribed to the Google Groups "PyFR Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyfrmailingli...@googlegroups.com.
To post to this group, send email to pyfrmai...@googlegroups.com.
Visit this group at http://groups.google.com/group/pyfrmailinglist.
For more options, visit https://groups.google.com/d/optout.
<naca_0012_coarse.msh><naca_0012_2d.ini>

[Zach Davis]

Hi Peter,

Thanks for getting to this for me.  Would you be able to describe for me the requisite input parameters for these characteristic boundary conditions?  It sounds like I may prefer to utilize those.  When using the non-dimensional form, are you indicating it is easier for the solver or from a user-perspective.  I don’t have a preference whether the variables are dimensionalized prior to the simulation running or during post-processing; though, at some point along the way I will need to do it.  Although, I guess I prefer to see the output already in metrics to which I’m accustomed, so maybe I lied in my previous statement.  I’ll try reducing the time step further as well to cover all of my bases.

Best Regards,

Zach

[Vincent, Peter E]

Hi Zach,

For characteristic BCs I believe the syntax in 2D is:

[soln-bcs-$name]

type = char-riem-inv

rho = ...

u = ...

v = ...

p = ...

Whether you go non-dimensional or not is largely down to personal preference - for me it simplifies things.

I would certainly try reducing the time step - however I am pretty certain you will also need to run on a finer mesh than the one you attached here initially.

Cheers

Peter

[Zach Davis]

All,

I've attached a finer mesh that includes 8960 quad elements which I'm using, and I have reduced my time step to 1.0e-6 (which is pretty small given my experience even for explicit Runge Kutta schemes), but I'm finding the solution still diverges after the first solution file is output.  I have also removed the inadvertent extra line space within the initial conditions block of my *.ini file which Peter pointed out.  Could the issue be somewhere else, or is the mesh in this case still too coarse?  Are there other relaxation controls that I'm overlooking?  I'm not sure the characteristic boundary conditions in this case provide any advantage over the sub-in-fpttang and sub-out-fp boundary conditions I'm using.  Again, any input would be appreciated.

Best Regards,

Zach

[Antony Farrington]

Hi Zach,

I have taken a quick look at your problem, and also at the finer mesh that you have attached; the nominal size of elements close to the aerofoil is now about right (for p=3), but I have a few further suggestions:

1.) The fluid domain is very large relative to the aerofoil. Whilst such large sizes are suggested for CFD validation, they are also difficult and expensive to work with. I would suggest using a smaller domain in this first instance: around ten times the size of the aerofoil. Once the simulation is running, it is a simple task to expand the domain and check for any untoward interactions with the fluid boundaries.

2.) It is generally best to avoid large jumps in element sizes. In practice: the smoother the transition, the better.

3.) I would also recommend switching to non-dimensional form. In particular, there is a very low free-stream density being set in this case (of order 1e-4), which could well be the primary problem. Also--on a human level--it would make checking for consistent units much faster (at least for me). I've not had time to check this, but it is always worth checking again.

Best,

Antony

--

Antony Farrington MEng ACGI AMIMechE
Postgraduate Researcher
Department of Aeronautics
Imperial College London

[Zach Davis]

Hi Antony,

I’ve gone ahead and non-dimensionalized my input parameters, and it seems to have resolved my issue.  Thanks to both you and Peter for making that suggestion.  I realize my mesh transitions in some regions could use some improvement, but I’m just getting started with Gmsh.  There are still several best practices I’m learning how to implement within the program, coupled with trying to ascertain how coarse I can go with a curvilinear mesh and get away with it.  I made the overall domain intentionally large, so I could “Rescale" it…

I’ve attached my new input file if any you think it might make a worthwhile example case, or for anyone just getting started and comes across this thread.

Best Regards,

Zach Davis
	Rescale, Inc. 589 Howard Street, Ste. 2 San Francisco, CA 94105 za...@rescale.com P: (855) 737-2253

enc