|
courant number increases to rather large values
1 Attachment(s)
Dear,
I have been facing the problem below for two geometries. Code:
/*---------------------------------------------------------------------------*\The checkMesh is OK. The createPatch to create the cyclic boundaries is OK. The timestep is 0.0125, even if I changed it to 1e-8, there is still such problems. And there is nothing new if I changed the Re to a very small value. I suspect there is something wrong with the geometry. But the error shows up again for the third geometry. An example geometry is attached. I wonder if you guys could give some instructions on this problem. Thank you in advance. Best Regards, Bill |
Large Courant numbers mean the time step ist too large. I see your time step is 10 ms. This is not especially small for complex geometries. Please keep in mind: Complex geometry = many nodes = small element sizes = small time for traversing an element = high Courant number.
The first steps have a small Courant number because the flow is zero initially. At least I suppose so. If you can afford the simulation time use a much smaller time step. I guess you need far below 1 ms, rather 100 µs. If that ist not possible you have to reduce the complexity of the geometry. That may lead to coarse solutions for some regions of your model. In that case I recommend to use the coarse solution as a starting point for isolating a Region Of Interest and simulating this region isolated. This makes much more manual effort, of course. |
Moreover if you use the adjustRunTime option in the controlDict together with the maxCo option you can let the solver choose the right timestep each time to stay under the MaxCo value of the Courant Number.
|
Dear,
Thank you for your replies. Dr. Pilz, I have tried to use timestep=1e-8s, the problem also appears. In my case, this is rather a small value and quite impossible for my simulation, since I need to run for 3e4s to ensure that I can observe the flow unsteadiness. I have read through other threads https://www.cfd-online.com/Forums/op...ets-large.html https://www.cfd-online.com/Forums/op...r-icofoam.html https://www.cfd-online.com/Forums/op...nt-number.html It seems that this way does not work. Dear Ruben, According to what I have read, it seems that the adjustRunTime and MaxCo options are not designed for icoFoam. I think I need to check the geometry over and over again, since one geometry is executable without this problem. Any possible reason (except the geometry) for this problem is still welcomed. Thank you. Best, Bill |
If I understand the geometry right you try to simulate some kind of draining through a porous material like sand or rubble. If I am right I recommend:
- Use a very small clipping first - Look at your boundary conditions. What is the b.c. for the particles? General the first thoughts should be sacrificed to "What I want to find out" and next "How can this be simulated in an easy way". More complicated and complex conditions may added later. It would be helpful to know what you try to find out and which purpose your simulation serves. ~ > controlDict together with the maxCo option This doesn't work with icoFoam, at least with my version of OF. pimpleFoam is able to accept these entries. |
Dear Dr. Pilz,
Thank you for you detailed reply. 1) Reducing the time-step does not solve the problem, only delay the time for the occurance of the error. 2) You are right, I am modeling the flow in the porous media. I started from a simple case and then complex geometry. Interesting thing is that, one of the complex geometries works well, giving me the good results, while for other complex geometries, the courant number will increase. The checkMesh function in OpenFOAM gives me the following information. Code:
Time = 0I wonder if there is any other possible reasons for this error, since all the settings in OpenFOAM are totally the same and there seems to be nothing wrong with the mesh. I have looked some related threads, but no final reasons for this error. Thank you. Best, Bill |
It is hard to give an advice at this level of information.
I see two possible reasons: 1) There is something wrong with the mesh. 2) The problem gets instabil with larger complexity You may set the end time to a point where the Courant number does not exceed 1 and look at the solution. If you have probems with the mesh you should find ares where the flow and pressure changes fast. Increasing Co number means that there is a very large flow somewhere. If you find any mistake this way and believe in your mesh, the you could play around with underrelaxation. Another way is slightly increasing the complexity and looking, when the problem starts to occur. In general, complex simulations are often more problematic because of numeric problems solving system of equations. If possible you may switch to an approximation technique. But I have experineces with that in OF. But I would look at the mesh first, which is often the problematic part in such instabilities. |
Code:
*Number of severely non-orthogonal (> 70 degrees) faces: 9. But the flow can be very complex in local areas. For example, in my case, there was a recirculation of the flow, with huge velocities, in the area where the severe non-orthogonal elements are detected. Maybe you should take a look on the area concerned by this warning about the non-orthogonality, i guess that you will find a particular area with recirculations or things like that. |
Areas with high flow need to meshed finer. A good measure of the real mesh quality is the relation between the max and mean Courant number, which should be low. You may get an idea of the flow values even from a coarse and imperfect mesh. Use that to establish a better mesh.
It is a fine idea only to use hex elements. Simulation is more stable in this case. Automated meshers don't reach the quality of a good manual mesh. |
Dear Laurant,
Thank you for the reply. Yes, you are right. This is most probably the reason for this problem. I will try to figure the "severely non-orthogonal" problems. Thank you. Cheers, Bill |
Quote:
I was also facing the same problem with icoFoam, where the Courant Number increases to a very large number. But finally I resolved. It can be solved by the following: 1. Use pimpleFoam with laminar module. 2. Modify the mesh. 3. If you still want to use icoFoam and do not want to do any change in mesh, then manually calculate (roughly), the maximum velocity in steady state condition. Using the minimum mesh size that you had used, and limiting the Courant number to 1, determine the minimum time step required. With a bit of factor of safety (decrease the value a bit), put the time step in controlDict. Hope this will work. Thanks, Jagannath |
Having similar problem
I also have similar problems and doing searches in this forum. I currently using Abaqus CFD and runs satisfactorily. I wants to try out OpenFOAM becaujse of its capability in multiphase problems.
I tried running CFD for three intake manifold models for car engines, two out of three models have Courant numbers large right from the start of the simulations even though the checkMesh reports ok, and both simulations blew up very soon. When the simulations could still running I could see pimpleFoam do adjust the time step to even ~1e-12 s, as I turned on maxCo option (which set to 1, 0.45 or even 0.1). What is interesting (or frustrating ... :() is that the same meshes ran perfectly in Abaqus CFD. The 3d meshes consists of tetrahedral and penta elements. All have penta elements modelling the boundary layers. The geometry of the intake manifolds are always complex, making the mesh entirely out of brick (hexa) elements are just not possible, and because of relatively tight project schedule we cannot afford very long run time and very big problem size. The models are intake manifolds for car engines, geometries were input, clean-up and meshed in ANSA (BetaCAD system). Snappyhexmesh was not used, as doing geometry clean-up is much easier in ANSA, and my computer runs on Window 7 (My OpenFOAM v5 is actually on Bluecore CFD). I read the posts in this thread, if as piu58 said only hex elements are fine for OpenFOAM then I have a feeling that the problems I dealt with might be difficult for OpenFOAM ... :( |
Quote:
By the way generally the problem you're facing is associated with wrong BCs. Are you sure that you translated the boundary conditions correctly from Abaqus to OF? |
Boundary conditions
Hi tidusuper91,
Just back, all three cases there is velocity at inlet and pressure at outlet, these are same in both Abaqus CFD and OpenFOAM runs. Because of IP protection issue I cannot share the files, I summarise the BCs below, one from successful model, the other two from failed models: This is from a successful model, running with Spalart Allmaras turb model: Inlet: p - zeroGradient U - surfaceNormalFV, value -10 (m/s) nut - calculated, value uniform 0 nuTilda - fixedValue, 0.01 Outlet (one of the engine cylinder port): p - fixedValue, 0 U - zeroGradient nut - calculated, value uniform 0 nuTilda - zeroGradient Wall and all the other closed engine cylinder ports: p - zeroGradient U - noSlip nut - nutkWallFunction, Cmu 0.09, kappa 0.41, epsilon 9.8, value uniform 0 nuTilda - zeroGradient This is from a failed model, also running with Spalart Allmaras turb model: Inlet: p - zeroGradient U - surfaceNormalFV, value -29.16 (m/s) nut - calculated, value uniform 0 nuTilda - fixedValue, 0.01 Outlet (one of the engine cylinder port): p - fixedValue, 0 U - zeroGradient nut - calculated, value uniform 0 nuTilda - zeroGradient Wall and all the other closed engine cylinder ports: p - zeroGradient U - noSlip nut - nutkWallFunction, Cmu 0.09, kappa 0.41, epsilon 9.8, value uniform 0 nuTilda - zeroGradient This is from another failed model, running with k-epsilon turb model: Inlet: p - zeroGradient U - surfaceNormalFV, value -17.67(m/s) k - fixed value, 1. epsilon - fixedValue, 1. Outlet (one of the engine cylinder port): p - fixedValue, 0 U - zeroGradient k - zeroGradient epsilon - zeroGradient Wall and all the other closed engine cylinder ports: p - zeroGradient U - noSlip k - kqRWallFunction, value uniform 1. epsilon - epsilonWallFunction, value uniform 1. |
Hi,
I am also working with flow in the porous media (in between the gap of two spheres). I am using interFoam solver. After running for quite some time, the deltaT goes to very low value(1e-108 or something). I am using constantAlphaContactAngle condition on the sphere walls. Interestingly, when I use zeroGradient boundary condition for alpha, the program runs well. Any idea what may be going wrong? |
Quote:
Well, that hints that probably you're setting wrong BCs. :) Could it be? |
Actually, I want to see the effect of contact angle on the liquid flow process. Hence, i want to put the solid liquid contact angle conditions.
Moreover, I made my mesh from sappy Hex mesh. The following are my BCS for alpha, U and p_rgh respectively - /*--------------------------------*- C++ -*----------------------------------*\ ========= | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox \\ / O peration | Website: https://openfoam.org \\ / A nd | Version: 7 \\/ M anipulation | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class volScalarField; object alpha.water; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [0 0 0 0 0 0 0]; internalField uniform 0; boundaryField { atmosphere { type zeroGradient; } two_sphere_bottom_sphere { type zeroGradient; } two_sphere_top_sphere { type zeroGradient; } } /*--------------------------------*- C++ -*----------------------------------*\ ========= | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox \\ / O peration | Website: https://openfoam.org \\ / A nd | Version: 7 \\/ M anipulation | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class volVectorField; location "0"; object U; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [0 1 -1 0 0 0 0]; internalField uniform (0 0 0); boundaryField { atmosphere { type pressureInletOutletVelocity; value uniform (0 0 0); } two_sphere_bottom_sphere { type noSlip; } two_sphere_top_sphere { type noSlip; } } /*--------------------------------*- C++ -*----------------------------------*\ ========= | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox \\ / O peration | Website: https://openfoam.org \\ / A nd | Version: 7 \\/ M anipulation | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class volScalarField; object p_rgh; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [1 -1 -2 0 0 0 0]; internalField uniform 0; boundaryField { atmosphere { type fixedValue; value uniform 0; } two_sphere_bottom_sphere { type fixedFluxPressure; } two_sphere_top_sphere { type fixedFluxPressure; } } Can you tell me what may be going wrong? if it is the mesh, then what shall improve? |
Quote:
Code:
CODEWhat's your mesh? Showing up the mesh could actually help to understand better if you put the right BCs. Reading the name of the patches is not really enough :) |
1 Attachment(s)
I have attached the wireframe of the mesh structure. The two half spheres are top sphere and bottom sphere respectively, and the other portions are atmosphere.
|
Quote:
|
| All times are GMT -4. The time now is 05:12. |