[podallaire]

Hi,

I'm facing some challenges when using extrudeMesh and wondering if it could be related to addr2line4Mac.py. I have cases that crash without any reason (mostly segmentation fault) and the same cases run no problem under Linux machines. Could it has to do something with addr2line4Mac.py and the fact that I'm running OpenFOAM under Mavericks ?

I have a clean install of Mavericks, gcc 4.6 compiled from sources and everything works pretty well with OpenFoam except extrudeMesh.

Let me know if you guys experience the same problems.

Thanks

PO

[wyldckat]

Greetings Pierre-Olivier,

Example of the output you're seeing would come in handy, in order to try and figure out the problem.

Also, an example case or an indication of a tutorial where this happens, would also be helpful.

In addition, did you do anything to "addr2line4Mac.py" during the installation procedure?

Best regards,
Bruno

[gschaider]

Originally Posted by podallaire

Hi,

I'm facing some challenges when using extrudeMesh and wondering if it could be related to addr2line4Mac.py. I have cases that crash without any reason (mostly segmentation fault) and the same cases run no problem under Linux machines. Could it has to do something with addr2line4Mac.py and the fact that I'm running OpenFOAM under Mavericks ?

I have a clean install of Mavericks, gcc 4.6 compiled from sources and everything works pretty well with OpenFoam except extrudeMesh.

Let me know if you guys experience the same problems.

Thanks

PO

No. addr2line is only involved BECAUSE a problem occurred. Usually at a failure OF dumps a stack-trace with (if this debug-information is present) the names of the source files and the lines in that source-file. On Mac OS X there is no API to get that information directly (or at least I didn't find it). addr2line.py is a utility that gets the address where the problem occurred calls gdb, asks for the source file information on that address and returns it. Sometimes this doesn't work.

But it is only called when a problem occurs. So as Bruno said an output of the error would be helpful

[podallaire]

Originally Posted by gschaider

No. addr2line is only involved BECAUSE a problem occurred. Usually at a failure OF dumps a stack-trace with (if this debug-information is present) the names of the source files and the lines in that source-file. On Mac OS X there is no API to get that information directly (or at least I didn't find it). addr2line.py is a utility that gets the address where the problem occurred calls gdb, asks for the source file information on that address and returns it. Sometimes this doesn't work.

But it is only called when a problem occurs. So as Bruno said an output of the error would be helpful

Hi guys,

the extrudeMesh process in the wingMotion tutorial fails for me

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Selecting extrudeModel linearNormal
Extruding from patch using model linearNormal
Not collapsing any edges after extrusion

Extruding patches 1(front) on mesh "../wingMotion_snappyHexMesh"

Create mesh for time = 0

Adding overall 0 processor patches.
Moving mesh to layer0 points since differ from original points - this can happen for wedge extrusions.

Testing:"../wingMotion_snappyHexMesh/system/fvSchemes"
Mesh bounding box : (-1.67021e+45 -2.58578e+45 -2.31584e+77) (3.53806e+44 9.23849e+44 0.15)
        with span : (2.02401e+45 3.50962e+45 2.31584e+77)
Merge distance    : 0

Writing mesh to "/Volumes/OpenFOAM/OpenFOAM-2.2.x/tutorials/incompressible/pimpleDyMFoam/wingMotion/wingMotion2D_simpleFoam/constant/region0"

End

Anything similar on your machines ? Pretty sure that it worked well under Mountain Lion, not sure what is going on here.

Thanks

[gschaider]

Originally Posted by podallaire

Hi guys,

the extrudeMesh process in the wingMotion tutorial fails for me

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Selecting extrudeModel linearNormal
Extruding from patch using model linearNormal
Not collapsing any edges after extrusion

Extruding patches 1(front) on mesh "../wingMotion_snappyHexMesh"

Create mesh for time = 0

Adding overall 0 processor patches.
Moving mesh to layer0 points since differ from original points - this can happen for wedge extrusions.

Testing:"../wingMotion_snappyHexMesh/system/fvSchemes"
Mesh bounding box : (-1.67021e+45 -2.58578e+45 -2.31584e+77) (3.53806e+44 9.23849e+44 0.15)
with span : (2.02401e+45 3.50962e+45 2.31584e+77)
Merge distance : 0

Writing mesh to "/Volumes/OpenFOAM/OpenFOAM-2.2.x/tutorials/incompressible/pimpleDyMFoam/wingMotion/wingMotion2D_simpleFoam/constant/region0"

End

Anything similar on your machines ? Pretty sure that it worked well under Mountain Lion, not sure what is going on here.

Thanks

Works for me (2.2.x pulled 3 weeks ago).

Go to the snappy-case and do "checkMesh -constant". I think that that case is already messed up. If the snapped mesh is already faulty then remove it. Redo blockMesh and check that (sounds silly, I know)

[podallaire]

Originally Posted by gschaider

Works for me (2.2.x pulled 3 weeks ago).

Go to the snappy-case and do "checkMesh -constant". I think that that case is already messed up. If the snapped mesh is already faulty then remove it. Redo blockMesh and check that (sounds silly, I know)

Sorry for the delay. I tried this without any success, I still get weird numbers in the extruded mesh. Also, I have noted that in this example, the blockMesh side patches are set to "empty" patches before running snappy and it's kept this way for the extruding process as well. Is this a good practice ?

Don,t know what is wrong with my extrudeMesh - I also recompiled with a different gcc version but same results.

Thanks

[wyldckat]

Greetings to all!

@Pierre-Olivier: Let's try to isolate the problem. If you run this command:

find $FOAM_TUTORIALS -name Allrun | xargs grep extrude

you'll find several tutorials that use extrudeMesh.
So try to run each tutorial, to double check if this is a problem with extrudeMesh or with the tutorial you've been testing.
If any other tutorial presents the same problem, it will be easier to assess what might be going on.

Because I vaguely remember seeing such a bug, but it was a long time ago and with an older version of OpenFOAM.

Best regards,
Bruno

[podallaire]

Hi,

sorry for the delay on responding to this. I actually cannot run the test: I updated my git installation this week and I'm having challenges recompiling libOpenFAM. Something is wrong with db/dynamicLibrary/codedBase/codedBase.C

Anybody haven the same issue ? I also tried using Clang and the appropriate patches, same problem.

Thanks

PO

[gschaider]

Originally Posted by podallaire

Hi,

sorry for the delay on responding to this. I actually cannot run the test: I updated my git installation this week and I'm having challenges recompiling libOpenFAM. Something is wrong with db/dynamicLibrary/codedBase/codedBase.C

Anybody haven the same issue ? I also tried using Clang and the appropriate patches, same problem.

Thanks

PO

"something is wrong" is a bit unspecific. If I hadn't already fixed that problem I wouldn't have bothered any further. Attached is a patch that fixes a problem about codedBase (not sure whether it is yours) and which I will fold into the general Mac-patch later this weekend

fixCodeBase.patch

[podallaire]

Thanks for the patch !

I recompiled, works great, no issue so far. I don't understand what was wrong with extrudeMesh - I ran some cases including the wing motion tutorial without any problem ?! I'll keep testing but so far so good