Hello Giorgio, Sorry to bother you again, since we had some had some discussion on ac-zeta selection.
So, I am currently running a bluff body case on 2nd order first, then switching to 4th order. It keeps breaking. Sometimes I found that dropping ac-zeta can prevent it from breaking, sometimes I found that reducing pseudo-dt can prevent it from breaking, or ultimately reducing dt can prevent it from breaking (which is not something I want to do..). For the case I am running now, Inlet velocity I set as 1, max velocity in the domain is around 2,3. Smallest cell in the mesh is 0.01. In the 2nd order run I set dt = 0.0005, pseudo-dt = 0.0001 which makes the Courant number significantly smaller than 1. I understand that dt should drop as we go for higher order. I am thinking if there is a way to keep it from diverging by using some specific ac-zeta? what is the physical significance of ac-zeta? What kinds of difference will it make if I set ac-zeta = 9 versus ac-zeta =1.1? I have seen that suggested value of ac-zeta is between 1 and 10 times the max velocity. What I feel now is smaller ac-zeta somehow reduces the chance of diverging, but it only works to certain level. Currently, seems that I made it run by reducing pseudo-dt. I am also not sure why this happens.. I don't have the result yet, so don't know if it really works... As far as I understand pseudo-time step acts like inner iterations. So is there any guideline on choosing the right pseudo-dt? Best regards, Junting Chen 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/d067b127-9236-4208-a074-c51fb6941a46%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
