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
On 11/06/14 22:08, Zach Davis wrote:
> 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
>
> On Tuesday, June 10, 2014 6:04:38 PM UTC-7, Vincent, Peter E wrote:
>
> 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
>
> On 11 Jun 2014, at 01:51, Zach Davis <[email protected]
> <javascript:>> wrote:
>
>> 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
>>
>> On Jun 10, 2014, at 5:23 PM, Vincent, Peter E
>> <[email protected] <javascript:>> wrote:
>>
>>> 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
>>>
>>> On 11 Jun 2014, at 00:21, Zach Davis <[email protected]
>>> <javascript:>> wrote:
>>>
>>>> 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
>>>>
>>>> --
>>>> 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 [email protected]
>>>> <javascript:>.
>>>> To post to this group, send email to
>>>> [email protected] <javascript:>.
>>>> Visit this group at
>>>> http://groups.google.com/group/pyfrmailinglist
>>>> <http://groups.google.com/group/pyfrmailinglist>.
>>>> For more options, visit https://groups.google.com/d/optout
>>>> <https://groups.google.com/d/optout>.
>>>> <naca_0012_coarse.msh><naca_0012_2d.ini>
>>>
>>
>
> --
> 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 [email protected]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at http://groups.google.com/group/pyfrmailinglist.
> For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
To post to this group, send an email to [email protected].
Visit this group at http://groups.google.com/group/pyfrmailinglist.
For more options, visit https://groups.google.com/d/optout.
