rhosimplefoam : error in solving the energy equation
1 Attachment(s)
Hi,
I am trying to use openfoam for a compressible case with rhosimplefoam solver but I have always the same error after 3 iterations. It seems that the error happens with the energy equation during the calculation of the pressure. I'am studying the drag coefficient on an intake. I have tried to make a calculation without my geometry. (only a simple blockmesh) and I obtain the same error ... I try to change my boundary conditions and the different solvers/schemes but i always obtain the same result. The calculation works with the incompressible solver simplefoam. I am sorry, i have not internet on the computer with openfoam so i post a screen of the error message Attachment 47737 Have you any idea about a way to solve my probleme ? Thank you for your attention fvsolution : Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ p : Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ |
I'm using rhoSimpleFoam as well and facing almost the same problem, my calculation breaks down after 30 iterations while calculating the pressure. My fvSchemes and fv Solution folders are almost identical than yours.
I managed to prolongate the number of iterations before breakdown by strongly decreasing the relaxation Factors (for p, down to 0.1). Maybe try to initialize the fields with a potential calculation by adding Code:
potentialFlow I see that you're using GAMG solvers. I don't know how many cells your mesh has and on how many cores your simulation is running, but maybe you should adapt ''nCellsInCoarsestLevel'' to the size of your mesh. The GAMG solver coarsens the initial Mesh by aglomerating cells together and nCellsInCoarsestLevel represents the number of cells in the coarsest level. A good approach is to set it to approx. sqrt(Number of Mesh Cells). If possible, don't use more than 16 cores with this kind of solver, otherwise, switch to a PCG solver. I ran out of ideas how to fix this case, i tried almost everything and it keeps crashing after a few iterations. Is anyone else facing this issue with rhoSimpleFoam or knows how to keep it running until convergence? Cheers! Charles |
Hi,
thank you for your reply. I have a mesh with only 1 million of cells and I work with a quadcore. I will try to apply your advices to see if they improve the calculation. I don't understand why it doesn't work .. I have no problem with the tutorial. Maybe it comes from the openfoam version ? I use the 3.01 version . One of my professor asked a Phd student who used openfoam in compressible case to see if he understands what's the problem; I am waiting for his answer. cordially Zal |
Ok, then set nCellsInCoarsestLevel to 1024 and see if it is running faster.
I didn't solve the problem either... I created a very simple geometry to test the rhoSimpleFoam solver with the identical settings. The calculation broke down after a few iterations, so same problem here... I tried with many different fvSolution settings and finally managed to keep the calculation runing by finding the correct relaxationFactors in the SIMPLEL Loop. Also nNonOrthogonalCorrectors has an important effect. The rhoSimpleFoam solver is a real pain in the neck :rolleyes: Of course it could also have something to do with your OF version but i'm using the 2.3.1 version and i'm facing the same issue... Now i'm trying to find the correct settings for my real case. Please let me know if you find a better way to keep the simulation stable. Cheers! |
Hi,
I think I solved my problem .. I applied your advices and I corrected some stupid mistakes in my blockmeshdict and now the calculation is working (900 iterations) . I have not changed anything else so I don't know if I can help you but if you want I can post again my files. I don't know if you are aware but with compressible cases openfoam works with the mach number in U and not the speed in m/s. I didn't know it so maybe it's your problem ? thank you for your help and your advices Zal |
I'm happy that I could help you! Hope it's going to converge now.
It would be great if you could post your fvSolution file again, i would like to see which relaxationFactors worked for your case. In your first post, I noticed that you set rhoMin & rhoMax in the SIMPLE Loop to 0.1 & 1. I don't know what Fluid you're using but with these settings, your calculation is quite constricted because the density can't grow above 1. Cheers |
2 Attachment(s)
I am sorry I have not internet on the computer where i use Openfoam.
I can only post screens. Attachment 47894 Attachment 47895 good luck to solve your problems ! Don't hesitate if I can help you. |
I am sorry but I have an other question.
My teacher says me that it's better to use the mach number with compressible cases but in several examples on the internet people use the speed in m/s. So I don't know what i should choose. My calculation works well when I use the mach number but my density has significant and anomalous variations when I use the speed in m/s. Other question : if I use mach number in my U file, I have to use the mach number in my forcesCoeff file ? cordially Zal |
Hi Zal and thanks for your pictures.
Unfortunately, I don't know if it's possible to define the Ma-Number in the U file. As default, the dimensions in U are always [0 1 -1 0 0 0 0], so m/s. Setting the Ma-Number right away seems to be impossible, as far as I know. There is a Mach utility in OpenFoam for post processing which allows you to calculate Ma out of your results for U. Maybe there is a special boundary condition that takes the Ma-Number as an entry value. Have you looked in the user Guide? If you're working with high Ma-Numbers, you should try do use sonicFoam and compare your results. Cheers! Charles |
Hi,
I remark that the problem doesn't come from the fvsolution file but from the boundary conditions in the 0 file. By example, if I used an uniform fixedvalue for U at inlet, my calculation doesn't work. But if I use the airflow (in order to have the same speed at inlet), I have no more problem. Zal |
Yes, same for me! I changed the pressure BC for the Inlet patch from fixed value to zeroGradient and specified the pressure for the Outlet patch and managed to keep the simulation running.
I think that the most instability problems occur because of problematic BC combination, even if they appear to be correct. With relaxation factors lower than 0.3, there shouldn't be any instability issues if the BC are set correctly. Charles |
Hi,
Juste a message to say that I find a new way to improve the stability of the calcualtion. If I use the "faceMDLimited Gauss linear 0.5;" for the gradSchemes it can help to solve some stability problemes. |
Ok Thanks, I will give it a try!
|
Hi there Charles,
regarding the GAMG solver I'd like some clarification if you can :) Quote:
Quote:
Thanks a lot. Lefteris |
Quote:
Hi Zal, I'm a bit confused as to how you set your Mach number in the 0/U file. Mach is dimensionless and the velocity in U is in m/s as Charles mentioned. The only way that I'm aware to get your velocity is to calculate the speed of sound from the freestream conditions and work out your freestream V from the Mach number. |
Sorry, it was an error, I suppose that my teacher didn't use the same solver as me.
|
Hi Lefteris,
I can't justify why sqrt(Number of Mesh Cells) is a good approach to set the number of cells. In my opinion it would be bad to define a number of cells that is much smaller than the real number of cells (huge jumps between coarsening steps). So maybe the square root is a good compromise. What i said about the nr. of cores for the GAMG solver wasn't exactly true. In fact, the GAMG algorithm agglomerates the cells of your mesh in bigger packs to form a coarser grid. Now if you decompose your Mesh for a parallel calculation, you also increase the amount of necessary communication between each CPU. OpenFOAM even tells you the number of neighbors a decomposed region has. So i believe that the GAMG algorithm, which also divides a mesh in certain region, is not ideal for strong parallelisation as the communication effort between each processor increases. But i recently heard that this characteristic is negligible for moderate parallelisation, which means under 100 or 150 CPUs. I am currently using GAMG with 24 processors and am able to calculate twice as fast, compared to calculations with a PCG solver. Cheers :) |
Hi Charles,
Thanks for your reply! I believe we are on the same wavelength for the GAMG solver. I don't like using only few cells as in some cases it messes up the solution altogether. I'm just trying to find the optimum setting and the explanation here ;) As for the decomposition, I normally use no more than 24 cores as, like you said, there's no benefit for my simulations if I use more. I think however, that decomposition and the time the simulation takes (taking into account communication etc) is very system dependent. Once again, thanks for your reply. |
Hello Antoine,
I got the same issue as you had. The calculation stopped at 9th iteration and came up with the error when solving energy equation. My goal is to solve a pressure driven problem for a tank with 1 inlet and 2 outlet. As you guys discussed here, I knew that a given value of outlet pressure should work fine with a flow rate inlet. So I set my boundary conditions like below. But I still got the error. Do you have any idea on it? Any of your input would be appreciated. Thank you! Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ |
I habe two suggestions:
1.) Try using sensibleEnthalpy instead of sensibleInternalEnergy in your thermophysicalProperties 2.) OpenFoam's Steady-State-Solver is not that stable as Fluent for example. It helps to give a initialisation so that the solver does not have to calculate the field from 0. I would try to use potentalFoam for your case. It calculates really fast a first velocity field and overwrites the U in your 0-Folder (so make a backup). You can use the initial field for rhoSimpleFoam. The setup for potentialFoam should be somewhere in the tutorials. |
All times are GMT -4. The time now is 14:09. |