Great! Thanks for clearing things out! Junting
On Monday, June 24, 2019 at 12:11:55 PM UTC-4, Giorgio Giangaspero wrote: > > 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/91a956e0-d8cc-45b5-882b-a905b84cfbe6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
