
[Sponsors] 
May 25, 2016, 12:33 
rhosimplefoam : error in solving the energy equation

#1 
New Member
Antoine
Join Date: Jun 2015
Posts: 12
Rep Power: 4 
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 error.png Have you any idea about a way to solve my probleme ? Thank you for your attention fvsolution : Code:
/** C++ **\  =========    \\ / F ield  OpenFOAM: The Open Source CFD Toolbox   \\ / O peration  Version: v3.0+   \\ / A nd  Web: www.OpenFOAM.com   \\/ M anipulation   \**/ FoamFile { version 2.0; format ascii; class dictionary; location "system"; object fvSolution; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // solvers { p { solver GAMG; tolerance 1e08; relTol 0.1; smoother GaussSeidel; nPreSweeps 0; nPostSweeps 2; nFinestSweeps 2; cacheAgglomeration true; nCellsInCoarsestLevel 20; agglomerator faceAreaPair; mergeLevels 1; } "(Uekepsilon)" { solver GAMG; tolerance 1e08; relTol 0.1; smoother GaussSeidel; nPreSweeps 0; nPostSweeps 2; nFinestSweeps 2; cacheAgglomeration true; nCellsInCoarsestLevel 20; agglomerator faceAreaPair; mergeLevels 1; } } SIMPLE { nNonOrthogonalCorrectors 0; rhoMin 0.1; rhoMax 1.0; transonic yes; consistent yes; residualControl { p 1e3; U 1e4; e 1e3; // possibly check turbulence fields "(kepsilonomega)" 1e3; } } relaxationFactors { fields { p 0.3; rho 0.3; } equations { p 0.3; U 0.7; e 0.7; k 0.7; epsilon 0.7; } } Code:
/** C++ **\  =========    \\ / F ield  OpenFOAM: The Open Source CFD Toolbox   \\ / O peration  Version: v3.0+   \\ / A nd  Web: www.OpenFOAM.com   \\/ M anipulation   \**/ FoamFile { version 2.0; format ascii; class dictionary; location "system"; object fvSchemes; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // ddtSchemes { default steadyState; } gradSchemes { default Gauss linear; } divSchemes { default none; div(phi,U) bounded Gauss upwind; div(((rho*nuEff)*dev2(T(grad(U))))) Gauss linear; div(phi,e) bounded Gauss upwind; div(phi,epsilon) bounded Gauss upwind; div(phi,k) bounded Gauss upwind; div(phid,p) bounded Gauss upwind; div(phi,Ekp) bounded Gauss upwind; div((phiinterpolate(rho)),p) Gauss upwind; } laplacianSchemes { default Gauss linear corrected; } interpolationSchemes { default linear; } snGradSchemes { default corrected; } fluxRequired { default no; p; } // ************************************************************************* // Code:
/** C++ **\  =========    \\ / F ield  OpenFOAM: The Open Source CFD Toolbox   \\ / O peration  Version: v3.0+   \\ / A nd  Web: www.OpenFOAM.com   \\/ M anipulation   \**/ FoamFile { version 2.0; format ascii; class dictionary; location "constant"; object thermophysicalProperties; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // thermoType { type hePsiThermo; mixture pureMixture; transport sutherland; thermo hConst; equationOfState perfectGas; specie specie; energy sensibleInternalEnergy; } mixture { specie { nMoles 1; molWeight 28.9; } thermodynamics { Cp 1004; Hf 2.544e+06; } transport { As 1.4792e06; Ts 116; } } // ************************************************************************* // Code:
/** C++ **\  =========    \\ / F ield  OpenFOAM: The Open Source CFD Toolbox   \\ / O peration  Version: v3.0+   \\ / A nd  Web: www.OpenFOAM.com   \\/ M anipulation   \**/ FoamFile { version 2.0; format ascii; class dictionary; location "constant"; object turbulenceProperties; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // simulationType RAS; RAS { RASModel kEpsilon; turbulence on; printCoeffs on; } // ************************************************************************* // p : Code:
/** C++ **\  =========    \\ / F ield  OpenFOAM: The Open Source CFD Toolbox   \\ / O peration  Version: v3.0+   \\ / A nd  Web: www.OpenFOAM.com   \\/ M anipulation   \**/ FoamFile { version 2.0; format ascii; class volScalarField; object p; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [1 1 2 0 0 0 0]; internalField uniform 7.5e+3; boundaryField { walls_2 { type zeroGradient; } inlet { type zeroGradient; } outlet { type fixedValue; value uniform 7.5e+3; } } // ************************************************************************* // Code:
/** C++ **\  =========    \\ / F ield  OpenFOAM: The Open Source CFD Toolbox   \\ / O peration  Version: v3.0+   \\ / A nd  Web: www.OpenFOAM.com   \\/ M anipulation   \**/ FoamFile { version 2.0; format ascii; class volVectorField; object U; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [0 1 1 0 0 0 0]; internalField uniform (0.7 0 0); boundaryField { walls_2 { type fixedValue; value uniform (0 0 0); } inlet { type fixedValue; value uniform (0.7 0 0); } outlet { type zeroGradient; } } // ************************************************************************* // 

May 26, 2016, 08:44 

#2 
Member
Charles K.
Join Date: Feb 2016
Location: Germany
Posts: 37
Rep Power: 3 
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 { nNonOrthogonalCorrectors 3; } 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 

May 28, 2016, 05:07 

#3 
New Member
Antoine
Join Date: Jun 2015
Posts: 12
Rep Power: 4 
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 

May 28, 2016, 08:46 

#4 
Member
Charles K.
Join Date: Feb 2016
Location: Germany
Posts: 37
Rep Power: 3 
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 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! 

May 31, 2016, 07:54 

#5 
New Member
Antoine
Join Date: Jun 2015
Posts: 12
Rep Power: 4 
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 

May 31, 2016, 08:27 

#6 
Member
Charles K.
Join Date: Feb 2016
Location: Germany
Posts: 37
Rep Power: 3 
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 

May 31, 2016, 12:41 

#7 
New Member
Antoine
Join Date: Jun 2015
Posts: 12
Rep Power: 4 
I am sorry I have not internet on the computer where i use Openfoam.
I can only post screens. IMG_20160531_150949.jpg IMG_20160531_150958.jpg good luck to solve your problems ! Don't hesitate if I can help you. 

June 1, 2016, 04:08 

#8 
New Member
Antoine
Join Date: Jun 2015
Posts: 12
Rep Power: 4 
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 

June 1, 2016, 04:33 

#9 
Member
Charles K.
Join Date: Feb 2016
Location: Germany
Posts: 37
Rep Power: 3 
Hi Zal and thanks for your pictures.
Unfortunately, I don't know if it's possible to define the MaNumber in the U file. As default, the dimensions in U are always [0 1 1 0 0 0 0], so m/s. Setting the MaNumber 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 MaNumber as an entry value. Have you looked in the user Guide? If you're working with high MaNumbers, you should try do use sonicFoam and compare your results. Cheers! Charles 

June 6, 2016, 07:11 

#10 
New Member
Antoine
Join Date: Jun 2015
Posts: 12
Rep Power: 4 
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 

June 6, 2016, 07:19 

#11 
Member
Charles K.
Join Date: Feb 2016
Location: Germany
Posts: 37
Rep Power: 3 
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 

June 14, 2016, 10:32 

#12 
New Member
Antoine
Join Date: Jun 2015
Posts: 12
Rep Power: 4 
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. 

June 15, 2016, 04:00 

#13 
Member
Charles K.
Join Date: Feb 2016
Location: Germany
Posts: 37
Rep Power: 3 
Ok Thanks, I will give it a try!


August 10, 2016, 04:55 

#14  
Senior Member
Lefteris
Join Date: Oct 2011
Location: UK
Posts: 199
Rep Power: 7 
Hi there Charles,
regarding the GAMG solver I'd like some clarification if you can Quote:
Quote:
Thanks a lot. Lefteris
__________________
Lefteris 

August 10, 2016, 05:00 

#15  
Senior Member
Lefteris
Join Date: Oct 2011
Location: UK
Posts: 199
Rep Power: 7 
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.
__________________
Lefteris 

August 10, 2016, 06:07 

#16 
New Member
Antoine
Join Date: Jun 2015
Posts: 12
Rep Power: 4 
Sorry, it was an error, I suppose that my teacher didn't use the same solver as me.


August 10, 2016, 09:47 

#17 
Member
Charles K.
Join Date: Feb 2016
Location: Germany
Posts: 37
Rep Power: 3 
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 

August 10, 2016, 11:15 

#18 
Senior Member
Lefteris
Join Date: Oct 2011
Location: UK
Posts: 199
Rep Power: 7 
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.
__________________
Lefteris 

Tags 
rhosimplefoam error 
Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
How I can introduce my power heat (W) in chtMultiRegionFoam?  aminem  OpenFOAM PreProcessing  28  July 15, 2016 08:57 
Extrusion with OpenFoam problem No. Iterations 0  Lord Kelvin  OpenFOAM Running, Solving & CFD  8  March 28, 2016 11:08 
Floating point exception error  lpz_michele  OpenFOAM Running, Solving & CFD  53  October 19, 2015 02:50 
simpleFoam error  "Floating point exception"  mbcx4jc2  OpenFOAM Running, Solving & CFD  12  August 4, 2015 02:20 
Orifice Plate with a fully developed flow  Problems with convergence  jonmec  OpenFOAM Running, Solving & CFD  3  July 28, 2011 05:24 