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
naca_0012_coarse.msh (139 KB)
naca_0012_2d.ini (2.08 KB)
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)
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
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
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
naca_0012_mid.msh.gz (2.88 MB)
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
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
naca_0012_2d.ini (2.18 KB)