|
[Sponsors] |
SimpleFoam high time-step continuity error on a simple geometry |
![]() |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
![]() |
![]() |
#21 | |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 ![]() |
Quote:
If you create the first (cyclic) case, create it in a way that it's outlet already lies at exactly the same position as the inlet of your current (second) case, same coordinates and same direction. Just as in the picture of the thread I linked above. This works... If you have problems, just write me.
__________________
The skeleton ran out of shampoo in the shower. |
||
![]() |
![]() |
![]() |
![]() |
#22 |
New Member
Chris Stiapis
Join Date: Mar 2014
Posts: 19
Rep Power: 12 ![]() |
In my case the velocity and the pressure at the inlet are both known. (feed is a pump fixed flowrate and pressure)
The problem that when I'm defining the pressure on the inlet my solutions explodes, some insane velocities pop out of the blue. That's why I have put zerogradient on the inlet. I think by doing so, the solution is stable but I'm loosing important information. #As fas as I'm aware in Navier-Stokes equations the pressure gradient drives the flow.# I tried many combinations of boundary conditions but none of them converges. |
|
![]() |
![]() |
![]() |
![]() |
#23 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 ![]() |
Ok, I don't think you can set pressure value at inlet and outlet and velocity at the inlet at once. This will end up in over determination.
For incompressible flow, You can 1) set inlet pressure and outlet pressure, velocity gradient at inlet and outlet. This will define the amount of flow through your system by the pressure difference. You can not additionally set the velocity. 2) set outlet (or inlet) pressure and velocity inlet, but with zero gradient for pressure at the other side. For me case "2" is standard. Edit: I think I did not understand you correctly. Now: Setting velocity and pressure value at inlet and both zero gradient at outlet should work... I think.
__________________
The skeleton ran out of shampoo in the shower. |
|
![]() |
![]() |
![]() |
![]() |
#24 |
New Member
Chris Stiapis
Join Date: Mar 2014
Posts: 19
Rep Power: 12 ![]() |
Dear Rodriguez,
The simulation managed to converged after 25000 iterations. The total cummulative error reduced to 10^-9. So for my case at least for now the problem is solved. Now, I tried just becasuse I'm curious to see what will hapen if i define the pressureand the velocity at the inlet. As u said it shouldn't be any issues, but I get this error message Code:
#0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::sigFpe::sigHandler(int) at ??:? #2 in "/lib/x86_64-linux-gnu/libc.so.6" #3 Foam::GAMGSolver::scale(Foam::Field<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const at ??:? #4 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ??:? #5 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:? #6 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:? #7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ??:? #8 at ??:? #9 at ??:? #10 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #11 at ??:? Floating point exception (core dumped) |
|
![]() |
![]() |
![]() |
![]() |
#25 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 ![]() |
Hmm... I don't understand this. For incompressible flow, the absolute pressure value doesn't mean anything, so it should be completely unimportant where in the domain the pressure is "hard-wired". Can you upload the whole case?
__________________
The skeleton ran out of shampoo in the shower. |
|
![]() |
![]() |
![]() |
![]() |
#26 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 ![]() |
Anyway: the four outlets are all outlets to the ambient pressure? Is that correct?
__________________
The skeleton ran out of shampoo in the shower. |
|
![]() |
![]() |
![]() |
![]() |
#27 |
New Member
Chris Stiapis
Join Date: Mar 2014
Posts: 19
Rep Power: 12 ![]() |
The outlets are placed at the bottom of a vessel. The pressure on the outlets in pout=rho*g*h=995*9.81*4.5----> the height of the water level.
I think in this cases the pressure on the outlet and is equal to the hydrostatic pressure. |
|
![]() |
![]() |
![]() |
![]() |
#28 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 ![]() |
That means, that the pressure at the four outlets is imposed by the ambience, i.e. the height of the water and not by the air flow of your simulation domain? So from the CFD point of view it is a boundary condition? Is that right?
__________________
The skeleton ran out of shampoo in the shower. |
|
![]() |
![]() |
![]() |
![]() |
#29 | |
New Member
Chris Stiapis
Join Date: Mar 2014
Posts: 19
Rep Power: 12 ![]() |
Quote:
I cannot upload the case, there is a limitation on the MB that someone can upload. http://www.filedropper.com/wholecase |
||
![]() |
![]() |
![]() |
![]() |
#30 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 ![]() |
Chris, this doesn't work as you think. If you have a fixed outlet pressure as in your case, you can not fix the inlet flow and inlet pressure by a pump. This is not possible. You can either fix the flow and some pressure drop over your domain will develop, or you can fix the pressure drop and some mass-flow will develop. Both doesn't work. This is true for both the experiment and the simulation.
I will have a look at your case anyway. You are fine. See this post: http://www.cfd-online.com/Forums/ope...tml#post201915
__________________
The skeleton ran out of shampoo in the shower. |
|
![]() |
![]() |
![]() |
![]() |
#31 |
New Member
Chris Stiapis
Join Date: Mar 2014
Posts: 19
Rep Power: 12 ![]() |
Rodriguez, what do you think about the boundary conditions ???
Cause the last thing you told me made me worried. Are u aware of any similar case ??? |
|
![]() |
![]() |
![]() |
![]() |
#32 |
Senior Member
anonymous
Join Date: Aug 2014
Posts: 205
Rep Power: 13 ![]() |
Are you using nonOrthogonalCorrectors?
Could you try fixing velocity in outlet and fixing pressure in inlet? Just the opposed as what you are doing. I think there is a problem with your boundary conditions. |
|
![]() |
![]() |
![]() |
![]() |
#33 |
New Member
Chris Stiapis
Join Date: Mar 2014
Posts: 19
Rep Power: 12 ![]() |
SSS, No I'm not using non orthogonal correctors, cause mesh non orthogonality is below 60.
I did as u suggested and i get this error message Code:
#0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::sigFpe::sigHandler(int) at ??:? #2 in "/lib/x86_64-linux-gnu/libc.so.6" #3 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) at ??:? #4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:? #5 Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const at ??:? #6 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ??:? #7 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:? #8 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:? #9 Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ??:? |
|
![]() |
![]() |
![]() |
![]() |
#34 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 ![]() |
Chris, your boundary conditions are fine. Just at the outlet for pressure you try to set two different conditions: fixed value and zero gradient. Just delete the line with "zero gradient".
Also, set relTol for all solvers to "0.1" I recommend to set outlet pressure to zero, because you will be able to see much more in the pictures after the simulation has run. Just bear in mind that this doesn't change the result at all, except that your absolute pressure value changes. Not the relative pressure (i.e. difference) between inlet and outlet. When you get that error message, do you try to set inlet and outlet pressure? This doesn't work in combination with setting inlet velocity, as I tryed to explain.
__________________
The skeleton ran out of shampoo in the shower. |
|
![]() |
![]() |
![]() |
![]() |
#35 |
Senior Member
anonymous
Join Date: Aug 2014
Posts: 205
Rep Power: 13 ![]() |
I downloaded your testcase and modified the following, for me it's running now:
First of all I added a ";" in the p boundary field, next time try to upload something that works ![]() After that I went to fvSolution and then to SIMPLE dictionary: Code:
SIMPLE { nNonOrthogonalCorrectors 0; pRefCell 0; pRefValue 49000; residualControl { p 1e-8; U 8e-8; "(k|epsilon|omega)" 1e-8; } } I'm using OF230. |
|
![]() |
![]() |
![]() |
![]() |
#36 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 ![]() |
I agree with the other things you wrote, but if he sets the absolute pressure value at the outlet (what he did), this is not necessary. Only if he sets both inlet and outlet pressure to zero gradient.
__________________
The skeleton ran out of shampoo in the shower. |
|
![]() |
![]() |
![]() |
![]() |
#37 | |
Senior Member
anonymous
Join Date: Aug 2014
Posts: 205
Rep Power: 13 ![]() |
Quote:
I didn't know that Openfoam could handle that situacion without setting pRefCell, as I always used 0 anyway. But simpleFoam asked me to write in the fvSolution so I just wrote it and it worked. I will correct my post. Thank you very much |
||
![]() |
![]() |
![]() |
![]() |
#38 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 ![]() |
It can handle it, because by setting the outlet to some fixed value, you already have an absolute reference pressure inside your domain. It just won't use the pRef value in that case.
__________________
The skeleton ran out of shampoo in the shower. |
|
![]() |
![]() |
![]() |
![]() |
#39 |
New Member
gned
Join Date: Oct 2012
Posts: 18
Rep Power: 14 ![]() |
So Chris,
how did you solve your continuity errors on the pipe system ? Which are your suggestions for similar cases? In your last post you sent your last bcs on U and p but than said, on the contrary, you had to avoid the fixed pressure value at the outlets. So with which bcs you could solve the simulation and with which final fvSchemes of the many suggested? Are the pressures equal for all the outlets ? Your outlet discharge vessel was not pressurized ? Did you measure experimentally these pressures at the outlets to be sure? |
|
![]() |
![]() |
![]() |
![]() |
#40 |
New Member
gned
Join Date: Oct 2012
Posts: 18
Rep Power: 14 ![]() |
Hi ssss,
just a question about this old post #32 by you about settling the right bcs. I have to solve something similar to Chris problem. Unfortunately, contrary to him, I don't trust too much the experimental measures they gave to me, in particular about the p at the outlet. Usually, for the bcs classically on this kind of problems are used : inlet: p ---> zeroGradient U ---> flowRateInletVelocity outlets : p ----> fixedValue U ----> zeroGradient At the inlet, on the contrary, that is at the pump side my confidence on the the right values of p is more.So in your opinion, since I have big problems to get convergence as Chris had, can be the same if I try the other way : inlet : p ----> fixedValue U ----> zeroGradient outlets : p ---> zeroGradient U ---> flowRateInletVelocity (about this latter, since personally i have only one inlet but 4 different outlets, it's sufficient that I rename with createPatchDict all the outlets under the same boundary patch name and then the flowRate condition is managed right by the solver among the 4 outlets ?) These conditions I think are numerically wellposed, am I right ? Why do you think in such problems (flows through orifices/pipes restrictions) we have so many difficulties to converge in OF in general (I found many other people to complain about similar cases issues in the forum indeed)? thanks a lot |
|
![]() |
![]() |
![]() |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Rapidly decreasing deltaT for interDyMFoam | chrisb2244 | OpenFOAM Running, Solving & CFD | 3 | July 1, 2014 17:40 |
AMI interDyMFoam for mixer nu problem | danny123 | OpenFOAM Programming & Development | 8 | September 6, 2013 03:34 |
plot over time | fferroni | OpenFOAM Post-Processing | 7 | June 8, 2012 08:56 |
Full pipe 3D using icoFoam | cyberbrain | OpenFOAM | 4 | March 16, 2011 10:20 |
Convergence moving mesh | lr103476 | OpenFOAM Running, Solving & CFD | 30 | November 19, 2007 15:09 |