Proper settings for PimpleFoam Simulation
Hello,
I want to do a 3D transient simulation of a wing. However, I am not able to get pimple to converge. Maybe somebody can give me a hint. so heres what I do: I start the simulation with SimpleFoam and calculate 5000 timesteps. After that I switch to Pimple. My Settings are like this: Control dict: Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
Create time Hope somebody can help me? Thanks a lot in advance!! :) |
Hi,
I would think you should try this (might even use 0.9 if it is stable): Code:
relaxationFactors |
Hey Tom,
thanks for your reply. I will definitely try to increase the relaxation factors. However I thought making the relaxation factors bigger will make it more difficult for Pimple to converge. Thus i started with small relaxation factors. Am I wrong with this? Best, Mahe |
Hi Mahe,
Well for p you are relaxing the field, so it can only change by URF*(p-p_old), which means that changes in the field are slow with low underrelaxation. It may be that with too high URF your system becomes unstable and therefore cannot converge anymore. My experience with PIMPLE thus far is that 0.8-0.9 gives usually the best performance, but you will have to play around a bit for each particular case. Regards, Tom |
Hey Tom,
Thanks a lot for your help. It's good to know there is somebody out there helping :) So to sum it up and get it right: small relaxation factors = slow convergence, but stable high relaxation factors = fast convergence, maybe unstable? I have tried the settings you suggested, but still PIMPLE says it doesn't converge after the 20 iterations I have set. Therefore the simulation is not moving on in time. I am kind of lost now. I do not really care about my pressure residual. I mean it could be 0.1 and still the simulation could get me good results in forces, right? Furthermore I ran the same case in steady-state and the residual didn't change a lot, for the pressure it was around 0.1 to 0.01 and the forces were also stable. So how can I achieve the simulation just starts and moves on and then see how it goes? I took the residual control out and though the simulation will just calculate the timesteps, but it doesn't... thanks! |
Hi Mahe,
I just had a closer look at your output, it looks like the pressure equations need a lot of iterations maybe you can change the relTol for pressure solver to 0.05. If this does not help to get No Iterations down, then I think something is wrong with either mesh or boundary conditions, but than again you did get a result from simpleFoam. I would also suggest to make your pimpleFoam case separate from the simpleFoam case by copying the files from the 5000 folder to a new 0 folder and then run to endTime 2. If you want to keep it like this I would suggest to increase the time precision in controlDict to 12. Regards, Tom |
Hey Tom,
wow. Incredibly fast answer! Thanks for that. Actually I just had the same idea with creating a new folder and just did that an hour ago or so ;) I will try to change relTol. Thanks! Well, I am not to sure about the mesh, since this is my first 3D simulation and I am also not too familiar with OpenFoam and especially SnappyHexMesh. However when I run a checkMesh, it seems to be ok. Code:
/*---------------------------------------------------------------------------*\ 1. What counts for the pimple loop to end is the last Initial residual, right? 2. In every calculation step, Initial residual is p_old and final residual is p in your equation URF*(p-p_old)? => so multiplied with my relaxation factor it should give me the new Initial residual? 3. Still I am not sure, why my initial pressure residual starts with the same value for every iteration?! Shouldn't use the former calculated ones? Sorry for all the questions and again, thanks so much for your help!! My next steps will be: 1 changing the relTol 2 increase nNonOrthogonalCorrectors and see if it is better to recalculate the pressure in every iteration, since there it does decrease. I will let you know how this goes! Best, Mahe |
Hello.
Look at those three lines in Your checkMesh: 1. Max aspect ratio = 63... (I think it its pretty high) 2. Mesh non-orthogonality Max = 65 (I think it its pretty high) 3. Min volume = 1.025883e-12. Max volume = 14.76541. (Isn't that mesh-cell too big?) Maybe there is an answer? You should prepare better mesh. Or maybe You should try to set Your PIMPLE nNonOrthogonalCorrectors to something like 2 - 5. Have a nice day. |
Hey sheaker,
thanks for your answer. As I stated I use OpenFoam for about 5 months and SnappyHexMesh for maybe 2. I need it for my masterthesis. Therefore I am not completely sure what the maximum numbers are and trusted the checkMesh output. Another thing is that you have to specify every parameter of the Mesh, run SHM and then check the result. I am not sure how to find the places, where to increase the Mesh and even when how to fix that particular spot. Also I am a bit limited by my resources. My Mesh now has around 8-10mio cells which I don't want to increase much. Additionally I am calculating an wing, so I have small cells near the Wing-surface but the cells in the farfield are big (100m away). As I expect there isn't much going on at the farfield and therefore the big cells should be ok?! Best, Mahe |
As I wrote somewhere else, the Courant number is a better measure for the quality of you mesh. It describes the mesh under flow conditions. The relation between maximal and mean Courant number should be small. This evaluation may be done with an imperfect mesh.
|
Hi Piu,
I do not agree with your statement. It may be related to the efficiency of the mesh (especially for interior domain simulations), but if you use large cells in the outer domain of your mesh and small cells near the surface there is always going to be a large difference between mean and max value of the Courant number. This does not mean you have a bad quality mesh. With regards to the checkMesh report, I would agree that the non-orthogonality and skewness are a bit high. You may want to change these in the settings for quality with snappyHexMesh, but take care that there is still a decent boundary layer mesh. The aspect ratio does not scare me at all. Should be fine in case of boundary layer meshes. In fact I have had much higher aspect ratios and had no problems. Regards, Tom |
> if you use large cells in the outer domain of your mesh and small cells near the surface there is always going to be a large difference between mean and max value of the Courant number
No, that is not the case. The Co number gives how many cells the flow moves in a time step. If the mesh is well balanced the flow moves around the same number of cells in every point of the mesh. > large difference between mean and max value of the Courant number. This does not mean you have a bad quality mesh. For not too complex simulations you may be right. But for complex situations an unnecessary fine mesh means unnecessary number of unknowns and therewith a system of equations which is less well conditioned. This may lead to numerical problems. |
Quote:
Quote:
So I can not agree with you about this. |
Dear Tom,
thank you for that explanation. Of course, they contain much trueness. But I believe here are other aspects to take in concern too. > The mesh needs to have correct spatial resolution to capture gradients in your flow. This seems to be true. But in reality you need the exact flow only in some regions of your problem. In the case of the wing you have to chose a spatial resolution in the near of the wing which covers the gradients, no questions. Normally, away from the wing the flow need only to solve to an accuracy which is adequate for covering the retroactive effects to the wing. It is not necessary to solve every detail of an eddy far away form the wing. So there you may have a coarser mesh. It may be a good strategy to make it at least as coarse as the balance of Co dictates: this leads to less time steps and to a more stable system of eqautions. > not true since you also get more equations for the unknowns Of course you get more equations. Without that you could not calculate the problem without any additional assumptions. But solving the system of equation means (in principle) to subtract a line of the system from the other as often as you have lines = unknowns. With more equations you get an accumulation of two bad effects: 1) Rounding errors increase. This leads slowly to less correct solutions 2) The probability that you have to subtract two nearly identical lines from each other increases. If that happens, you make something like division by zero (not full zero, but a very small number). In this case the solution gets wrong or explodes. The probability increases too, if you have cells which small changes in the flow variables in one part of the mesh and cells with rapid changes in another part. I know that the more advanced solvers don't simply subtract lines, but the principal problems remains. The chance to have a higher condition number increases with number of equations and with the differences in the Courant number (small changes against large ones). |
All times are GMT -4. The time now is 15:51. |