I’m lookig at your ini file now, there are quite a few things wrong with it. Somethings to bear in mind:
A pressure of zero will always give issues
You didn’t increase the max pseudo iteration number as I recommended
You changed the pseudo-dt-fact to 50. This will definitely cause issues, this menas that as you do from the p-multigrid level p to p-1, the pseudo-dt in increasing by a factor of 50. Which will easily make things unstable.
You reduced nu to ~1e-6, this will make the Reynolds number very high and, unless you have enough mesh, will lead to instabilities.
In the integrate plugin I recommended you calculate the intgral of the absolute divergence, this is an important difference as the integral of divergence often equals zero whereas the pointwise values might not be zero.
I’ll let you know if I get a working inifile for your case
Thank you so much your supports. I could calculate my case 1 step without NAN.(Since the second and subsequent steps fall no matter how I do it, I may need to devise a way, so keep thinking of ways to make it work.) I attach ini file since I want you to review it in order to calculate it next the second and subsequent steps.)
By the way, in terms of velocity, pressure and nu(kinematic viscosity), What are the units? This is because I only know the no-dimensional NS equation and the units are not opened at User Guide.
Moreover , I would like to know how and where in codes Reynolds number and Mach number are defined.
Hi @Yujif1Aero, worth checking if your Uin value of 10 means your inflow velocity is 10 times the speed of sound. Can you describe the system you are trying to solve (i.e., mesh scale, input velocity, fluid viscosity). Also, might be worth getting this to run using the plain Navier-Stokes solver first.
Thank you for replyig.
I have tried to simulate the vortex around buldings.
inpul velocity is more than 10m/s, viscosity is air ( nu = 1.48e-5 )
In terms of mesh, I am not used to make mesh using Gmesh (I do not have commercial mesher eg pointwise) I also want to know how check the mesh scalse at wall but I only know automatic meshing by gmesh.( I am learning how to use gmesh now) If possible I want to calaculate it with mesh Y+=1 ~ 10 at wall.
Two points, you probably want to reduce the pseudo-niters-min, you don’t want to force the system to take 100 steps if it has already converged, 4 is probably more appropriate. For pseudo-niters-max, 100 is probably better too.
PyFR doesn’t assume units, see one of the many other posts asking similar questions.
For example:
Finally on you question about GMSH, this might be better asked to there support team/community.
In your case, I thought you were simulating a channel with an obstruction? I don’t see the obstuction in the pictures, rather, you seem to have mesh where it should be.
Edit: I looked at the mesh you sent previously and I now understand what your case look like.
The pressure at the inlet isn’t set by the ac-in-fv boundary and is free to change. Pressure waves will occur in incompressible fluids as the flow accelerates, initially you’ll see larger pressure waves as the solution settles down from the unrealistic IC to a more realistic state. You just have to power though this period and it normally takes a couple flow throughs of the domain. For example, given the size of the domain ([-10,10]^2\times[0,20]) and the inlet velocity (u=1), it may take until t=20 to 80 or longer. What you can do initially is reduce the order to order = 1 and increase nu. This does two things, the reduced order speeds up the simualtion and adds diffusion to damp out the waves. Increasing nu also add diffusion. Once the solution has developed you can then return the order and nu to the desired values.
Thank you for replyng so much.
I understood I needed to caluclate many period to get stable.
However I could not understand that if nu is increased, the diffusion is increasing.
Yep, changing nu will change the Retynolds number, but this is only for the initialisation. Once you’ve done some flow throughs, you then change it to the target order and nu.
Yep, it should be fine. The pyfr import doesn’t use the ini file so the pyfrm file is independent of the mesh order. Also looking at your domain, it should have entirely flat surfaces anyway.
That error is coming from p-multigrid, this isn’t to do with the mesh.
P-multigrid is a convergence accelleration method that can be simply decsribed as down sampling the solution to a lower order, solving that system, and using that low order data to help solve the high order system.
Try changing the solver-dual-time-integrator-multip section in the ini the following for order 1:
Thank your reply.
My case is working well at 1st-order of [solver-dual-time-integrator-multip] pseudo-dt-fact = 1.75 cycle = [(1, 1), (0, 4), (1, 4)] I am not sure what works best for my problem at 2nd and 3rd order.
Moreover I am not familiar with V cycle. What is V cycle?
