|
[Sponsors] |
![]() |
![]() |
#1 |
Guest
Posts: n/a
|
hello all,
I am using reactingFoam in a simple geometry with 2 inlets and a outlet.I have manually edited all the files of U,O2,etc.. but on solving with reactingFoam , I get the following error: #0 Foam::error::printStack(Foam: ![]() #1 Foam::sigFpe::sigFpeHandler(int) #2 ?? #3 Foam::polyMesh::calcDirections() const #4 Foam::polyMesh::directions() const #5 Foam::fvMatrix<foam::vector<double> >::solve(Foam::Istream&) #6 Foam::lduMatrix::solverPerformance Foam::solve<foam::vector<double> >(Foam::tmp<foam::fvmatrix<foam::vector<double> > > const&) #7 main #8 __libc_start_main #9 __gxx_personality_v0 What does this error mean?and how to resolve it? Thanks. Mayank. |
|
![]() |
![]() |
![]() |
#2 |
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51 ![]() ![]() |
That means that it fails while calling polyMesh::calcDirections() (the last Foam-code in the stack).
From the header of polyMesh we see that the purpose of this function is to "Calculate the valid directions in the mesh from the boundaries". My guess is that you mesh has a problem. Did you do a checkMesh? If you have a Debug-Version of OF-compiled the dump would also include the line number where it fails.
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request |
|
![]() |
![]() |
![]() |
![]() |
#3 |
Guest
Posts: n/a
|
Hi Bernhard,
I have a tetrahedral mesh, and I did the the checkMesh which was working properly.Can you suggest some other alternative. Thanks. Mayank |
|
![]() |
![]() |
![]() |
#4 |
Guest
Posts: n/a
|
I think I fixed it.I removed the defaultFaces patch -which was set to empty- from the boundary file.Now the reactingFoam runs fine.
|
|
![]() |
![]() |
![]() |
#5 |
New Member
abhishek k n
Join Date: Mar 2009
Location: Gothenburg, Sweden
Posts: 16
Rep Power: 17 ![]() |
Hi
Running a simple 2d configuration with inlet/outlet and wall boundaries. The solver used is simple Foam with k-e model. There is a error message #1 Foam::sigFpe::sigFpeHandler(int) #2 Uninterpreted: [0xffffe420] #3 Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) #4 void Foam::divide<foam::fvpatchfield,>(Foam::GeometricF ield<double,>&, Foam::GeometricField<double,> const&, Foam::GeometricField<double,> const&) #5 Foam::tmp<foam::geometricfield<double,> > Foam::operator/<foam::fvpatchfield,>(Foam::tmp<foam::geometricfie ld<double,> > const&, Foam::GeometricField<double,> const&) #6 Foam::turbulenceModels::kEpsilon::correct() #7 main #8 __libc_start_main |
|
![]() |
![]() |
![]() |
![]() |
#6 |
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51 ![]() ![]() |
Hi!
It happens at the first time-step, right? Check k and epsilon. ALL their initial and boundary conditions should be non-zero (I think one of yours is zero and that's why you're getting a division by zero)
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request |
|
![]() |
![]() |
![]() |
![]() |
#7 |
New Member
Karl-Heinz Leitz
Join Date: Mar 2009
Posts: 16
Rep Power: 17 ![]() |
Hallo,
I get a similar error. I am using a modified multiphaseinterfoam solver and at the beginning it seems to run quite stable. But at once, after more than 20 timesteps, I get the following error message: #0 Foam::error::printStack(Foam: ![]() #1 Foam::sigFpe::sigFpeHandler(int) #2 Uninterpreted: [0xb7f75420] #3 exp #4 Foam::exp(Foam::Field<double>&, Foam::UList<double> const&) #5 void Foam::exp<foam::fvpatchfield,>(Foam::GeometricFiel d<double,>&, Foam::GeometricField<double,> const&) #6 Foam::tmp<foam::geometricfield<double,> > Foam::exp<foam::fvpatchfield,>(Foam::tmp<foam::geo metricfield<double,> > const&) #7 main #8 __libc_start_main #9 Foam::regIOobject::readIfModified() Can anybody tell me what this message means or give me a hint where I have to look for the mistake? Greetings, Karl-Heinz |
|
![]() |
![]() |
![]() |
![]() |
#8 |
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51 ![]() ![]() |
Because this seems to be a very popular topic I have added a (very sparse) entry to the FAQ:
http://openfoamwiki.net/index.php/Main_FAQ (currently section 8.2 - the Message-Board-Software doesn't allow me to post the comple URL) @karl-heinz: Don't know what could be your concrete problem
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request |
|
![]() |
![]() |
![]() |
![]() |
#9 |
Member
Shaun Cooper
Join Date: Mar 2009
Posts: 54
Rep Power: 17 ![]() |
Hi All,
I get a similar error when running my model (modified sonicFoam): Courant Number mean: 0.11819 max: 0.567546 deltaT = 1 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 DILUPBiCG: Solving for Ux, Initial residual = 0.00509694, Final residual = 4.28543e-18, No Iterations 4 DILUPBiCG: Solving for Uy, Initial residual = 0.00546863, Final residual = 5.27391e-18, No Iterations 4 DILUPBiCG: Solving for Uz, Initial residual = 0.000589589, Final residual = 6.26821e-19, No Iterations 4 DILUPBiCG: Solving for e, Initial residual = 1.07501e-05, Final residual = 1.36064e-16, No Iterations 3 DILUPBiCG: Solving for p, Initial residual = 0.0236798, Final residual = 1.93664e-16, No Iterations 4 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 time step continuity errors : sum local = 8.73984e-16, global = -4.91172e-16, cumulative = 1.227e-13 DILUPBiCG: Solving for p, Initial residual = 0.00283702, Final residual = 1.0908e-17, No Iterations 4 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 time step continuity errors : sum local = 1.61059e-16, global = 2.10885e-17, cumulative = 1.22721e-13 #0 Foam::error::printStack(Foam: ![]() #1 Foam::sigFpe::sigFpeHandler(int) #2 Uninterpreted: [0x271420] #3 log10 #4 Foam::log10(Foam::Field<double>&, Foam::UList<double> const&) #5 void Foam::log10<foam::fvpatchfield,>(Foam::GeometricFi eld<double,>&, Foam::GeometricField<double,> const&) #6 Foam::tmp<foam::geometricfield<double,> > Foam::log10<foam::fvpatchfield,>(Foam::tmp<foam::g eometricfield<double,> > const&) #7 main #8 __libc_start_main #9 Foam::regIOobject::readIfModified() Floating point exception Am I correct in saying it is an error with the value passed to the log10 function? The only error I can think of for this is a value <= 0. However, in my output leading up to the error the field of concern is increasing to large values. Is there a limit to the value that the log10 function can take? Thanks Shaun |
|
![]() |
![]() |
![]() |
![]() |
#10 |
Senior Member
Join Date: Mar 2009
Posts: 225
Rep Power: 18 ![]() |
Hi everyone,
Got the same trouble, which is not good. Checked posted FAQ, but that DOES NOT help much. I tried to run the same example twice on the cluster machine. Both times parallel computation stopped at the same time around 2.6 second. Here I attach links to the last 200 output lines from both runs, so one can compare them. They generally look almost identical: http://www2.hawaii.edu/~krystian/tankTest/sample http://www2.hawaii.edu/~krystian/tankTest/sample2 Also, here is the TecPlot plot for the last step where data were written (2.6s). Computation actually broke for 2.617s. http://www2.hawaii.edu/~krystian/tankTest/tankflume.png Hope we will be able to solve that problem. Tomorrow, I will check the same example running on my Mac machine (no parallelization - single machine) - hope it finished. Krystian |
|
![]() |
![]() |
![]() |
![]() |
#11 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,906
Rep Power: 33 ![]() |
Your time step is 10e-11 seconds that's picoseconds, which is unlikely to be right. I think your simulation blew up beforehand (due to setup or choice of numerics errors) and this is just the automatic time-step control unsuccessfully trying to save you.
Have a CLOSE look at your case and the last results before delta t started going ridiculously small. Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
![]() |
![]() |
![]() |
![]() |
#12 |
Senior Member
Join Date: Mar 2009
Posts: 225
Rep Power: 18 ![]() |
Today, friend of mine more familiar with CFD is going to take a look at my results, so I could verify my setup.
However, I think there is something more which could be wrong. The same example runs with OpenFOAM-1.3 on my Mac machine and it already passed the 2.617 threshold and runs further - however computation is very long, already 3 days, but I blame this on computer hardware. I think the problem lies somewhere else. Krystian |
|
![]() |
![]() |
![]() |
![]() |
#13 |
Senior Member
Join Date: Mar 2009
Posts: 225
Rep Power: 18 ![]() |
Mistake found. Will run it again and will see what happens.
But anyway, the robust code should produce something else than just error::printStack. |
|
![]() |
![]() |
![]() |
![]() |
#14 |
Senior Member
Fabian Braennstroem
Join Date: Mar 2009
Posts: 407
Rep Power: 19 ![]() |
Hi all,
I have a slightly different error message for a buoyantSimpleFoam calcualation: Time = 1 DILUPBiCG: Solving for Ux, Initial residual = 1, Final residual = 7.69481e-06, DILUPBiCG: Solving for Uy, Initial residual = 1, Final residual = 1.58066e-06, DILUPBiCG: Solving for Uz, Initial residual = 1, Final residual = 7.40929e-06, #0 Foam::error::printStack(Foam: ![]() #1 Foam::sigFpe::sigFpeHandler(int) #2 ?? #3 Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<d #4 Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::surfaceMesh Field, Foam::surfaceMesh> const&, Foam::tmp<Foam::GeometricField<double, Foam::f #5 main #6 __libc_start_main #7 __gxx_personality_v0 at ../sysdeps/i386/elf/start.S:122 Floating exception Unfortunately, I am not quite sure, what it means!? I checked the initial and boundary conditions, but say look ok. Does anyone have an idea, where I have to look at? Regards! Fabian |
|
![]() |
![]() |
![]() |
![]() |
#15 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,906
Rep Power: 33 ![]() |
I bet it is a floating point exception: division by zero. Try
setenv FOAM_SIGFPE 1 and run it again. Precisely why you are trying to divide by zero might be a bit more difficult to find. Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
![]() |
![]() |
![]() |
![]() |
#16 |
Senior Member
Fabian Braennstroem
Join Date: Mar 2009
Posts: 407
Rep Power: 19 ![]() |
Hi Hrv,
I did set the FOAM_SIGFPE to one... it is the error message above. I would say, the messages says, that the boundary condition for the temperature is wrong (at least it occurs, when starting to calculate the energy equation), but I set all temperatures around 300K for the initial field and the inlets. Strange!? Regards! Fabian |
|
![]() |
![]() |
![]() |
![]() |
#17 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,906
Rep Power: 33 ![]() |
What is the initial value of the internal field?
Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
![]() |
![]() |
![]() |
![]() |
#18 |
Senior Member
Fabian Braennstroem
Join Date: Mar 2009
Posts: 407
Rep Power: 19 ![]() |
Uniform 300 for the internal and 299 and 301 for the 6 inlets.
Fabian |
|
![]() |
![]() |
![]() |
![]() |
#19 |
Senior Member
Fabian Braennstroem
Join Date: Mar 2009
Posts: 407
Rep Power: 19 ![]() |
Hi,
is there something else I might have to look at? Maybe, I should set the initial field using an old simpleFoam calculation ... I'll try it... Fabian |
|
![]() |
![]() |
![]() |
![]() |
#20 |
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51 ![]() ![]() |
Hi Fabian!
As your calculation went through the UEqn.H it seems to me that the problem might be in hEqn.H. There are two divisions by rho (which in turn is computed from p, I think). Question: is it possible that your initial p-Field is zero somewhere? (a favourite with compressible solvers) Bernhard
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request |
|
![]() |
![]() |
![]() |
|
|