[bennn]

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]

Hi,

Here's more detailed printStack:

#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:

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:

    ...
    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

...
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]

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]

If we try to estimate planarity of the boundary as



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

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

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]

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.