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]> 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]> 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].
>> To post to this group, send email to [email protected].
>> 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>
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to