simpleFoam/potentialFoam crash during fvc::reconstruct(phi);

bennn · November 10, 2016, 06:02

Hi all,

I'm getting a very strange potentialFoam crash, with very limited information :

#0 Foam::error:

rintStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 ? at tensorField.C:?
#4 ? at ??:?
#5 ? at ??:?
#6 ? at ??:?
#7 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#8 ? at ??:?

I could identify that this occur during fvc::reconstruct(phi);

One case would work, and suddenly it would occur with a very slight change to the input CAD : adding one point discretization to the CAD, or something similar.

You can find two cases below, generated by the exact same script, with this kind of very slight geometry change. If your run potentialFoam, one works, the other does not. checkMesh logs are very similar, and give no bad checks.

https://dl.dropboxusercontent.com/u/...geCrash.tar.gz

I've tried changing boundary condition, schemes, solvers... And I'm stuck now.

Any idea is welcome ! Thanks a lot.

alexeym · November 10, 2016, 11:15

Hi,

Here's more detailed printStack:

Code:

#0  "Foam::error::printStack(Foam::Ostream&)" in ~/OpenFOAM/OpenFOAM-4.x/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#1  "Foam::sigFpe::sigHandler(int)" in ~/OpenFOAM/OpenFOAM-4.x/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2  "_sigtramp" in /usr/lib/system/libsystem_platform.dylib
#3  ? in /usr/lib/system/libsystem_platform.dylib
#4  "void Foam::inv<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> const&)" in ~/OpenFOAM/OpenFOAM-4.x/platforms/darwin64ClangDPInt32Opt/bin/potentialFoam
#5  "Foam::tmp<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> > Foam::inv<Foam::fvPatchField, Foam::volMesh>(Foam::tmp<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> > const&)" in ~/OpenFOAM/OpenFOAM-4.x/platforms/darwin64ClangDPInt32Opt/bin/potentialFoam
#6  "Foam::tmp<Foam::GeometricField<Foam::outerProduct<Foam::Vector<double>, double>::type, Foam::fvPatchField, Foam::volMesh> > Foam::fvc::reconstruct<double>(Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&)" in ~/OpenFOAM/OpenFOAM-4.x/platforms/darwin64ClangDPInt32Opt/bin/potentialFoam
#7  "main" in ~/OpenFOAM/OpenFOAM-4.x/platforms/darwin64ClangDPInt32Opt/bin/potentialFoam
#8  "start" in /usr/lib/system/libdyld.dylib
#9  ? in /usr/lib/system/libdyld.dylib

You are right about location of sigFpe (fvc::reconstruct). More precisely it is in the call:

Code:

inv(surfaceSum(SfHat*mesh.Sf()))

in fvcReconstruct.C. inv(dimensionedSphericalTensor).

And finally if we try to find the reason for error in this inv call with something like:

Code:

    ...
    surfaceVectorField SfHat(mesh.Sf()/mesh.magSf());

    volTensorField l(fvc::surfaceSum(SfHat*mesh.Sf()));

    forAll(l.boundaryField(), i)
    {
        const auto& t = l.boundaryField()[i];
        Info << t.patch().name() << endl;
        forAll(t, j)
        {
            Info << "   " << j << ' ' << inv(t[j]) << endl;
        }
    }
    ...

output is

Code:

...
cyclic2
...
   1889 #0  "Foam::error::printStack(Foam::Ostream&)" in ~/OpenFOAM/OpenFOAM-4.x/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#1  "Foam::sigFpe::sigHandler(int)" in ~/OpenFOAM/OpenFOAM-4.x/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2  "_sigtramp" in /usr/lib/system/libsystem_platform.dylib
#3  ? in /usr/lib/system/libsystem_platform.dylib
#4  "start" in /usr/lib/system/libdyld.dylib
Floating point exception: 8
...

The reason? Description on cyclic boundaries?

bennn · November 13, 2016, 06:10

Right on spot, thanks for that ! So yes when I use another BC than cyclicAMI it solves the problem. I guess the issue is that the cyclicAMI boundaries are not perfectly planar, don't you think ?

I've had this kind of problem before with cfMesh when using symmetryPlane, and cfMesh comes with a little tool called improveSymmetryPlane, just for that. However it does not solve the issue there... I'll keep investigating.

On a side note, could you explain how you got all the detailed information in your log file ? Is it by compiling with the debug switch ?

Thanks a lot.

alexeym · November 14, 2016, 04:29

If we try to estimate planarity of the boundary as

$p = \frac{\sum_{i=1}^N\left|\vec{n_i} - \vec{n_0}\right|}{N}$

and collect the value over patches then in crash we'll get:

Code:

inlet -> (mean/min/max) 0/0/0
outlet -> (mean/min/max) 0/0/0
top -> (mean/min/max) 0.899109983859/0.00240276244157/1.6782288672
cyclic1 -> (mean/min/max) 1.43440756948e-06/6.88859781417e-10/1.5537488795e-05
cyclic2 -> (mean/min/max) 1.31060120671e-06/5.00398454048e-09/2.02451551045e-05
blade -> (mean/min/max) 1.13754771335/0.000879164564671/1.99999999318

and in ok

Code:

inlet -> (mean/min/max) 0/0/0
outlet -> (mean/min/max) 0/0/0
top -> (mean/min/max) 0.899109979388/0.00240276246383/1.6782288672
cyclic1 -> (mean/min/max) 1.45851551374e-06/6.29867927562e-10/1.88279589695e-05
cyclic2 -> (mean/min/max) 1.50303790729e-06/6.38616663096e-09/1.83836433187e-05
blade -> (mean/min/max) 1.13989044808/0.00175623855917/1.99999991869

cyclic2 in crash has greater max value. So it could be patch non-planarity and should be fixed by mesh modification or a bug in cyclicAMI and should be reported.

Concerning printStack output, guess clang/lldb do better job in generating source code map/address resolution than gcc/addr2line pair. On Linux you get similar output with WM_COMPILE_OPTION set to Debug.

bennn · November 16, 2016, 08:11

All right I got it ! I could solve some of this non-planarity issue in the CAD software, by better stl discretization around specific features.

Thanks a lot for your help, it is very much appreciated.

November 10, 2016, 06:02	simpleFoam/potentialFoam crash during fvc::reconstruct(phi);	#1
bennn Member benoit paillard Join Date: Mar 2010 Posts: 96 Rep Power: 16	Hi all, I'm getting a very strange potentialFoam crash, with very limited information : #0 Foam::error:rintStack(Foam::Ostream&) at ??:? #1 Foam::sigFpe::sigHandler(int) at ??:? #2 ? in "/lib/x86_64-linux-gnu/libc.so.6" #3 ? at tensorField.C:? #4 ? at ??:? #5 ? at ??:? #6 ? at ??:? #7 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #8 ? at ??:? I could identify that this occur during fvc::reconstruct(phi); One case would work, and suddenly it would occur with a very slight change to the input CAD : adding one point discretization to the CAD, or something similar. You can find two cases below, generated by the exact same script, with this kind of very slight geometry change. If your run potentialFoam, one works, the other does not. checkMesh logs are very similar, and give no bad checks. https://dl.dropboxusercontent.com/u/...geCrash.tar.gz I've tried changing boundary condition, schemes, solvers... And I'm stuck now. Any idea is welcome ! Thanks a lot.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[swak4Foam] swak4foam-0.3.0 make parallel run crash on foam-extend-3.0	Aleksey_R	OpenFOAM Community Contributions	12	March 22, 2019 08:57
Simulation crash with dynamicRefineFvMesh and kOmegaSST - OF 2.3.x	nathanael	OpenFOAM Running, Solving & CFD	4	June 29, 2014 18:02
Crash when using DPMfoam for LPT of objects contacting a vibrating wall	ansubru	OpenFOAM Running, Solving & CFD	0	May 1, 2014 04:24
Paraview crash	Nixlax	OpenFOAM Installation	4	February 15, 2014 18:21
Dragging Slice File = Crash	cbritan	OpenFOAM Bugs	3	January 6, 2011 04:58

November 13, 2016, 06:10		#3
bennn Member benoit paillard Join Date: Mar 2010 Posts: 96 Rep Power: 16	Right on spot, thanks for that ! So yes when I use another BC than cyclicAMI it solves the problem. I guess the issue is that the cyclicAMI boundaries are not perfectly planar, don't you think ? I've had this kind of problem before with cfMesh when using symmetryPlane, and cfMesh comes with a little tool called improveSymmetryPlane, just for that. However it does not solve the issue there... I'll keep investigating. On a side note, could you explain how you got all the detailed information in your log file ? Is it by compiling with the debug switch ? Thanks a lot.

November 14, 2016, 04:29		#4
alexeym Senior Member Alexey Matveichev Join Date: Aug 2011 Location: Nancy, France Posts: 1,938 Rep Power: 39	If we try to estimate planarity of the boundary as $p = \frac{\sum_{i=1}^N\left\|\vec{n_i} - \vec{n_0}\right\|}{N}$ and collect the value over patches then in crash we'll get: Code: inlet -> (mean/min/max) 0/0/0 outlet -> (mean/min/max) 0/0/0 top -> (mean/min/max) 0.899109983859/0.00240276244157/1.6782288672 cyclic1 -> (mean/min/max) 1.43440756948e-06/6.88859781417e-10/1.5537488795e-05 cyclic2 -> (mean/min/max) 1.31060120671e-06/5.00398454048e-09/2.02451551045e-05 blade -> (mean/min/max) 1.13754771335/0.000879164564671/1.99999999318 and in ok Code: inlet -> (mean/min/max) 0/0/0 outlet -> (mean/min/max) 0/0/0 top -> (mean/min/max) 0.899109979388/0.00240276246383/1.6782288672 cyclic1 -> (mean/min/max) 1.45851551374e-06/6.29867927562e-10/1.88279589695e-05 cyclic2 -> (mean/min/max) 1.50303790729e-06/6.38616663096e-09/1.83836433187e-05 blade -> (mean/min/max) 1.13989044808/0.00175623855917/1.99999991869 cyclic2 in crash has greater max value. So it could be patch non-planarity and should be fixed by mesh modification or a bug in cyclicAMI and should be reported. Concerning printStack output, guess clang/lldb do better job in generating source code map/address resolution than gcc/addr2line pair. On Linux you get similar output with WM_COMPILE_OPTION set to Debug. bennn likes this.

November 16, 2016, 08:11		#5
bennn Member benoit paillard Join Date: Mar 2010 Posts: 96 Rep Power: 16	All right I got it ! I could solve some of this non-planarity issue in the CAD software, by better stl discretization around specific features. Thanks a lot for your help, it is very much appreciated.