Hi Junting

keep in mind that the boundary conditions starting with 'ac' refer to the 
artificial comprehensibility method, which is what the incompressible 
solver is based upon. If the flow is incompressible then by definition the 
speed of sound goes to infinity and the Mach number is zero. Thus 
normailsing with respect to the speed of sound may not be the best option.

For the incompressible solver, I typically set in pyfr u=1,p=1 and then 
change the viscosity to obtained the desired Reynolds number (see the 
incompressible cylinder in the examples). With this choice the artificial 
compressibility variable zeta, ac-zeta=3 or 2.5, usually works fine. Also 
the boundary condition ac-char-riem-inv typically works well for the 
incompressible solver.

The choice of normalisation is up to you. In principle PyFR can be run with 
all dimensional values. However, for the incompressible solver I would 
suggest the numbers above.

Yes the initial condition for the cylinder was chosen to minimise the 
initial transients. Again the combination of variables (u,v,w,rho,p) and 
domain size (x,y,z) is such that you obtain the desired Reynolds and Mach 
number.

Best
Giorgio


On Wednesday, June 19, 2019 at 10:09:06 PM UTC+1, Junting Chen wrote:
>
> Hello Dr.Witherden,
>
> Since our discuss was nothing related to OpenMP or cuda, I think it would 
> be better to open another thread.
>
> So today instead of "u = 20", I used "u = 0.0583090", normalized by the 
> speed of sound. 
>
> I have tried cases such as:
>     - 2nd order and 4th order (to see result quicker, I chose 2nd order)
>     - ac-char-riem-inv for both inlet and outlet
>     - ac-in-fv for inlet and ac-out-fp for outlet
>     - initial condition of "u = 0.0583090"
>     - initial condition of "u = 0" with the expectation of seeing movement 
> of incoming flow profile approaching the bluff body
>
> I have not made it run properly yet. The central plane (y=0) looks like 
> after 40s - 200s in the cases above:
>
>
> [image: 1.PNG]
> Seems there is something preventing the incoming flow entering the fluid 
> domain from the left.
> In the case where initial condition of the fluid domain was set the same 
> as the inlet, the flow is not developing at all.
> Would you mind to take a brief look of my ini file and give me some hints? 
> What is the difference between using ac-char-riem-inv for both inlet and 
> outlet, and using ac-in-fv for inlet and ac-out-fp for outlet?
>
>
>
>
>
>
>
>
>
>
>
>
> I also noticed that in the example case couette_flow_2d, in the "ini" file 
> it stated that "Uw"=70 and "p=100000". Apparently these values are not 
> normalized. Please let me know in what situations the inlet velocity needs 
> to be normalized.
>
> Also, in the 3d_cylinder case (along with the publication), the initial 
> condition was set like: u    = 0.2366431913+0.001*z*yv    = 
> 0+0.001*z+0.01*cos(x)*cos(y)*cos(z)w    = 
> 0+0.001*z+0.01*cos(x)*cos(y)*cos(z)Is there any meaning behind them or 
> they were just optimized to push convergence? In the case, seems like not 
> only "u", "v", and "w", "x", "y", and "z" are normalized values as well. 
> Thanks a lot!Best regards,Junting Chen
>
>
>
>

-- 
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 https://groups.google.com/group/pyfrmailinglist.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/pyfrmailinglist/cf28310c-3111-49fb-878f-c1377fa607a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to