OF 1.9 (aka OF 2.1) on Mac OS X

gschaider · January 1, 2012, 17:35

Hi!

For those who haven't just applied the 2.0-patch to the shiny new OpenFOAM 2.1.x here comes a set of patches to get it to run.

This time you have the choice:
a) use the gcc 4.2 that comes with Apple XCode (advantage is: you'll only have to install one compiler)
b) use gcc 4.6 from MacPorts (advantage: supposedly faster)

Basically do the same as if you would install OF from sources on a Linux-Machine (so I'll be sketchy):

1. Download OF 2.1 (preferably via git) and Thirdparty-2.1 and unpack them on a case-sensitive filesystem (see elsewhere what this means)

2. Go to the ThirdParty-Directory and apply the first patch
patch -p1 <ThirdParty-2.1.0-Mac.patch

3. Go to the OpenFOAM-Directory and apply the base-patch
patch -p1 <OpenFOAM-2.1.x-Mac.patch
then make the script that helps with the tracedumps executable (if the patch-utilitiy didn't do it)
chmod a+x bin/addr2line4Mac.py

4. Now decide which compiler you're going to use (although you can also apply both patches if you want to)
a) gcc 4.2: apply the appropriate patch:
patch -p1 <OpenFOAM-2.1.x-gcc42.patch
(this patch fixes some places where gcc4.2 can't cope with advanced constructs)
b) gcc 4.6: apply
patch -p1 <OpenFOAM-2.1.x-Mac-gcc46.patch
and make sure that the WM_COMPILER environment variable is set to Gcc46 (preferably in site/2.1.x/prefs.sh)
c) other compiler: copy wmake/rules/darwinIntel.. that the patches create. Basically only the compiler name has to be changed in the c ant the c++-file if you use gcc

5. Now source etc/bashrc, grab some coffee and compile

As usual I didn't bother to get the PV3Reader (aka paraFoam) to compile. Use an up-to-date paraview from Kitware with the built in reader for OF

Bernhard

PS: comments on the procedure are welcome. If somebody feels like writing a step-by-step instruction on the Wiki this would be even more welcome

norman1981 · January 3, 2012, 13:27

Thank you, it worked well for me!

Regards

Norman

egp · January 4, 2012, 17:41

Hi Bernhard,

Worked like a charm. OF 1.9 is running on desktop iMac. Thanks!

However, the ThirdParty patch grumbled about scotch,

Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file scotch_5.1.11/src/Makefile.inc.rej

Makefile.inc.rej

[16:36:38][egp@wtmac:ThirdParty-2.1.x]513$ more scotch_5.1.11/src/Makefile.inc.rej
***************
*** 1 ****
- ../../etc/wmakeFiles/scotch/Makefile.inc.i686_pc_linux2.shlib-OpenFOAM-64--- 1 ----
+ ../../etc/wmakeFiles/scotch/Makefile.inc.i686_mac_darwin.shlib-OpenFOAM

wyldckat · January 4, 2012, 17:58

Greetings to all!

@Eric: don't worry about that, Allwmake in the "ThirdParty-2.1.0" folder will fix the issue on its own

@Bernhard: The following last lines in the ThirdParty patch can be removed:

Code:

diff --git a/scotch_5.1.11/src/Makefile.inc b/scotch_5.1.11/src/Makefile.inc
--- a/scotch_5.1.11/src/Makefile.inc
+++ b/scotch_5.1.11/src/Makefile.inc
@@ -1,1 +1,1 @@
-../../etc/wmakeFiles/scotch/Makefile.inc.i686_pc_linux2.shlib-OpenFOAM-64
\ No newline at end of file
+../../etc/wmakeFiles/scotch/Makefile.inc.i686_mac_darwin.shlib-OpenFOAM
\ No newline at end of file

Look mom, no Mac!

Best regards,
Bruno

gschaider · January 4, 2012, 20:46

Quote:

Originally Posted by wyldckat

Greetings to all!

@Eric: don't worry about that, Allwmake in the "ThirdParty-2.1.0" folder will fix the issue on its own

@Bernhard: The following last lines in the ThirdParty patch can be removed:

Code:

diff --git a/scotch_5.1.11/src/Makefile.inc b/scotch_5.1.11/src/Makefile.inc
--- a/scotch_5.1.11/src/Makefile.inc
+++ b/scotch_5.1.11/src/Makefile.inc
@@ -1,1 +1,1 @@
-../../etc/wmakeFiles/scotch/Makefile.inc.i686_pc_linux2.shlib-OpenFOAM-64
\ No newline at end of file
+../../etc/wmakeFiles/scotch/Makefile.inc.i686_mac_darwin.shlib-OpenFOAM
\ No newline at end of file

Look mom, no Mac!

Best regards,
Bruno

I think this part was taken from the 2.0-patch (where it made sense). I'll remove it

podallaire · January 6, 2012, 11:50

Quote:

Originally Posted by gschaider

I think this part was taken from the 2.0-patch (where it made sense). I'll remove it

Thanks Bernhard for the patches !

Did you try to run something parallel ? I'm having trouble here, I tried many different versions of openmpi but I just cannot get it to work. I never had this problem before on OSX. I'm getting something like this when I try to use snappyHexMesh :

Code:

Create time

Create mesh for time = 0

[0] 
[0] 
[0] --> FOAM FATAL IO ERROR: 
[0] error in IOstream "IOstream" for operation operator>>(Istream&, List<T>&) : reading first token
[0] 
[0] file: IOstream at line 0.
[0] 
[0]     From function IOstream::fatalCheck(const char*) const
[0]     in file db/IOstreams/IOstreams/IOstream.C at line 114.
[0] 
FOAM parallel run exiting
[0] 
[1] 
[1] 
[1] --> FOAM FATAL IO ERROR: 
[1] error in IOstream "IOstream" for operation operator>>(Istream&, List<T>&) : reading first token
[1] 
[1] file: IOstream at line 0.
[1] 
[1]     From function IOstream::fatalCheck(const char*) const
[1]     in file db/IOstreams/IOstreams/IOstream.C at line 114.
[1] 
FOAM parallel run exiting
[1]

I bench-tested all openmpi installations and did not get any problem. Would it be something to do with capturing the command line arguments ?

Regards,

PO

egp · January 6, 2012, 11:58

Yes, I'm having the same problem. My earlier post was prior to any parallel tests! I thought I had something broken in my MPI compilation, but tried several versions, too, with no luck.

Quote:

Originally Posted by podallaire

Thanks Bernhard for the patches !

Did you try to run something parallel ? I'm having trouble here, I tried many different versions of openmpi but I just cannot get it to work. I never had this problem before on OSX. I'm getting something like this when I try to use snappyHexMesh :

Code:

Create time

Create mesh for time = 0

[0] 
[0] 
[0] --> FOAM FATAL IO ERROR: 
[0] error in IOstream "IOstream" for operation operator>>(Istream&, List<T>&) : reading first token
[0] 
[0] file: IOstream at line 0.
[0] 
[0]     From function IOstream::fatalCheck(const char*) const
[0]     in file db/IOstreams/IOstreams/IOstream.C at line 114.
[0] 
FOAM parallel run exiting
[0] 
[1] 
[1] 
[1] --> FOAM FATAL IO ERROR: 
[1] error in IOstream "IOstream" for operation operator>>(Istream&, List<T>&) : reading first token
[1] 
[1] file: IOstream at line 0.
[1] 
[1]     From function IOstream::fatalCheck(const char*) const
[1]     in file db/IOstreams/IOstreams/IOstream.C at line 114.
[1] 
FOAM parallel run exiting
[1]

I bench-tested all openmpi installations and did not get any problem. Would it be something to do with capturing the command line arguments ?

Regards,

PO

gschaider · January 7, 2012, 13:51

Quote:

Originally Posted by podallaire

Thanks Bernhard for the patches !

Did you try to run something parallel ? I'm having trouble here, I tried many different versions of openmpi but I just cannot get it to work. I never had this problem before on OSX. I'm getting something like this when I try to use snappyHexMesh :

Code:

Create time

Create mesh for time = 0

[0] 
[0] 
[0] --> FOAM FATAL IO ERROR: 
[0] error in IOstream "IOstream" for operation operator>>(Istream&, List<T>&) : reading first token
[0] 
[0] file: IOstream at line 0.
[0] 
[0]     From function IOstream::fatalCheck(const char*) const
[0]     in file db/IOstreams/IOstreams/IOstream.C at line 114.
[0] 
FOAM parallel run exiting
[0] 
[1] 
[1] 
[1] --> FOAM FATAL IO ERROR: 
[1] error in IOstream "IOstream" for operation operator>>(Istream&, List<T>&) : reading first token
[1] 
[1] file: IOstream at line 0.
[1] 
[1]     From function IOstream::fatalCheck(const char*) const
[1]     in file db/IOstreams/IOstreams/IOstream.C at line 114.
[1] 
FOAM parallel run exiting
[1]

I bench-tested all openmpi installations and did not get any problem. Would it be something to do with capturing the command line arguments ?

Regards,

PO

Can't reproduce this. I usually test by running the damBreak-case in serial and parallel (did you try that). For me iglooWithFridges works alright on two processors.

Only problem (but it manifests in a different way) that I had that the OpenMPI from an old OF-Version "spoiled" the OF 2.1 (wrong dynamic libraries were used). Check with

otool -L $FOAM_LIBBIN/$FOAM_MPI/libPstream.dylib

that the right libraries are used (one problem is that this information is hardcoded into the library at compile time)

For the record: my versions are
- OS X 10.6
- MacPorts gcc46
- OpenMPI 1.2.8 in /usr (Yeah. It is that old. But it works)

Bernhard

podallaire · January 7, 2012, 14:32

Quote:

Originally Posted by gschaider

Can't reproduce this. I usually test by running the damBreak-case in serial and parallel (did you try that). For me iglooWithFridges works alright on two processors.

Only problem (but it manifests in a different way) that I had that the OpenMPI from an old OF-Version "spoiled" the OF 2.1 (wrong dynamic libraries were used). Check with

otool -L $FOAM_LIBBIN/$FOAM_MPI/libPstream.dylib

that the right libraries are used (one problem is that this information is hardcoded into the library at compile time)

For the record: my versions are
- OS X 10.6
- MacPorts gcc46
- OpenMPI 1.2.8 in /usr (Yeah. It is that old. But it works)

Bernhard

Here i'm using OS X 10.7, Xcode gcc-4.2 and openmpi 1.4.4 (also tried openmpi 1.5.3 and 1.5.4). The right libraries are used / really not sure what is the problem. I will give it a try with gcc 4.5 (which I compiled for OF-2.0.x) and see what happens.

Thanks

PO

gschaider · January 7, 2012, 18:07

Quote:

Originally Posted by podallaire

Here i'm using OS X 10.7, Xcode gcc-4.2 and openmpi 1.4.4 (also tried openmpi 1.5.3 and 1.5.4). The right libraries are used / really not sure what is the problem. I will give it a try with gcc 4.5 (which I compiled for OF-2.0.x) and see what happens.

Thanks

PO

Could you also tell me with which tutorial case you experienced the problem. In other words: does this only happen with snappyHexMesh or with other solvers/cases too?

podallaire · January 7, 2012, 19:15

Quote:

Originally Posted by gschaider

Could you also tell me with which tutorial case you experienced the problem. In other words: does this only happen with snappyHexMesh or with other solvers/cases too?

It's pretty much everything, all apps that I try to run parallel / snappy was just an example. The error message is the same for all applications.

Thanks

PO

podallaire · January 8, 2012, 09:20

Quote:

Originally Posted by podallaire

It's pretty much everything, all apps that I try to run parallel / snappy was just an example. The error message is the same for all applications.

Thanks

PO

Hi,

I re-compiled OF with gcc-4.5.3 and gcc-4.6.2 / parallel applications work, no problem here. So really, something is going on with Xcode gcc-4.2.

Have a good day

PO

egp · January 9, 2012, 11:44

Quote:

Originally Posted by podallaire

Hi,

I re-compiled OF with gcc-4.5.3 and gcc-4.6.2 / parallel applications work, no problem here. So really, something is going on with Xcode gcc-4.2.

Have a good day

PO

Hi PO,

This works, thanks. I installed gcc-4.6.2 using MacPorts, and recompiled OF. All is happy now in parallel.

lithos · January 18, 2012, 05:36

Dear all,

first I like to thank Bernhard for all the work on the Mac OS X version and the manuals for compiling etc.

I used the manual below on my Mac to compile OpenFOAM v2.1. The compilation itself worked, also the cavity example was ok. But when I read the output during the comilation and installation there are a lot of entries like theses ones:

....
could not open file faceIOList.H for source file reactingParcelFoam.C
could not open file labelIOList.H for source file reactingParcelFoam.C
could not open file polyBoundaryMesh.H for source file reactingParcelFoam.C
could not open file boundBox.H for source file reactingParcelFoam.C
could not open file pointZoneMesh.H for source file reactingParcelFoam.C
could not open file faceZoneMesh.H for source file reactingParcelFoam.C
could not open file cellZoneMesh.H for source file reactingParcelFoam.C
could not open file lduMesh.H for source file reactingParcelFoam.C
....

Could anyone of you explain this behaviour?

Configuration is Mac OS X 10.6.8 with gc-4.2.1 and OpenMPI 1.2.8 (Apple Developer standard configuration).

Thanks in advance for your help and have a nice day.

Cheers,

Michael

Quote:

Originally Posted by gschaider

Hi!

For those who haven't just applied the 2.0-patch to the shiny new OpenFOAM 2.1.x here comes a set of patches to get it to run.

This time you have the choice:
a) use the gcc 4.2 that comes with Apple XCode (advantage is: you'll only have to install one compiler)
b) use gcc 4.6 from MacPorts (advantage: supposedly faster)

Basically do the same as if you would install OF from sources on a Linux-Machine (so I'll be sketchy):

1. Download OF 2.1 (preferably via git) and Thirdparty-2.1 and unpack them on a case-sensitive filesystem (see elsewhere what this means)

2. Go to the ThirdParty-Directory and apply the first patch
patch -p1 <ThirdParty-2.1.0-Mac.patch

3. Go to the OpenFOAM-Directory and apply the base-patch
patch -p1 <OpenFOAM-2.1.x-Mac.patch
then make the script that helps with the tracedumps executable (if the patch-utilitiy didn't do it)
chmod a+x bin/addr2line4Mac.py

4. Now decide which compiler you're going to use (although you can also apply both patches if you want to)
a) gcc 4.2: apply the appropriate patch:
patch -p1 <OpenFOAM-2.1.x-gcc42.patch
(this patch fixes some places where gcc4.2 can't cope with advanced constructs)
b) gcc 4.6: apply
patch -p1 <OpenFOAM-2.1.x-Mac-gcc46.patch
and make sure that the WM_COMPILER environment variable is set to Gcc46 (preferably in site/2.1.x/prefs.sh)
c) other compiler: copy wmake/rules/darwinIntel.. that the patches create. Basically only the compiler name has to be changed in the c ant the c++-file if you use gcc

5. Now source etc/bashrc, grab some coffee and compile

As usual I didn't bother to get the PV3Reader (aka paraFoam) to compile. Use an up-to-date paraview from Kitware with the built in reader for OF

Bernhard

PS: comments on the procedure are welcome. If somebody feels like writing a step-by-step instruction on the Wiki this would be even more welcome

gschaider · January 18, 2012, 17:53

Quote:

Originally Posted by lithos

Dear all,

first I like to thank Bernhard for all the work on the Mac OS X version and the manuals for compiling etc.

I used the manual below on my Mac to compile OpenFOAM v2.1. The compilation itself worked, also the cavity example was ok. But when I read the output during the comilation and installation there are a lot of entries like theses ones:

....
could not open file faceIOList.H for source file reactingParcelFoam.C
could not open file labelIOList.H for source file reactingParcelFoam.C
could not open file polyBoundaryMesh.H for source file reactingParcelFoam.C
could not open file boundBox.H for source file reactingParcelFoam.C
could not open file pointZoneMesh.H for source file reactingParcelFoam.C
could not open file faceZoneMesh.H for source file reactingParcelFoam.C
could not open file cellZoneMesh.H for source file reactingParcelFoam.C
could not open file lduMesh.H for source file reactingParcelFoam.C
....

Could anyone of you explain this behaviour?

Configuration is Mac OS X 10.6.8 with gc-4.2.1 and OpenMPI 1.2.8 (Apple Developer standard configuration).

Thanks in advance for your help and have a nice day.

Cheers,

Michael

No explanation. I mean the only explanation I have is that the $FOAM_SRC/OpenFOAM/lnInclude-directory is missing/messed up. But I don't see how anything can compile then. The reactingParcelFoam-solver is there?

bigphil · January 18, 2012, 19:56

Quote:

Originally Posted by lithos

....
could not open file faceIOList.H for source file reactingParcelFoam.C
could not open file labelIOList.H for source file reactingParcelFoam.C
could not open file polyBoundaryMesh.H for source file reactingParcelFoam.C
could not open file boundBox.H for source file reactingParcelFoam.C
could not open file pointZoneMesh.H for source file reactingParcelFoam.C
could not open file faceZoneMesh.H for source file reactingParcelFoam.C
could not open file cellZoneMesh.H for source file reactingParcelFoam.C
could not open file lduMesh.H for source file reactingParcelFoam.C
....

Could anyone of you explain this behaviour?

I think this is because of "limit -n" on Mac being set to 256 by default (It is 1024 on Linux I think). "limit -n" is to do with the number of files that can be opened by a process.
To fix it, add the following line to your .bashrc:

Code:

# set higher limit for OpenFOAM wmake                                                                                                  
ulimit -n 1000

This sets it to 1000 and should stop wmake giving out about not being able to open files.

BTW the funny thing is that wmake still compiles fine even when it says it cannot find the files.

Philip

lithos · January 19, 2012, 09:07

Dear both,

the file reactingParcelFoam is there, but it does not work:

./reactingParcelFoam
dyld: Symbol not found: __ZTIN4Foam18cyclicAMIPolyPatchE
Referenced from: /Volumes/OpenFOAMv2.1/OpenFOAM-2.1.0/platforms/darwinIntel64GccDPOpt/bin/./reactingParcelFoam
Expected in: /Users/username/OpenFOAM/OpenFOAM-2.0.x/platforms/darwinIntel64Gcc45DPOpt/lib/libmeshTools.dylib
in /Volumes/OpenFOAMv2.1/OpenFOAM-2.1.0/platforms/darwinIntel64GccDPOpt/bin/./reactingParcelFoam

The lines cited above from compilation are just an example, there are a lot of other entries like that.
I also checked the ulimit, it is set to unlimited. In addition, the rights are set correct as far as I know, too. It is 755 or drwxr-xr-x right now.

So I do not understand why I got these problems, but I will give it another try with a newer compiler today.

Thanks for your help. Please let me know if you have another idea.

Cheers,

Michael

lithos · January 19, 2012, 14:18

Ok. It does work now. You were totally right with the ulimit. Just typing ulimit on two different macs give back unlimited. But ulimit -n gives back 256. So I changed it to ulimit -n 1024 and it works very fine. Thanks again

Quote:

Originally Posted by lithos

Dear both,

the file reactingParcelFoam is there, but it does not work:

./reactingParcelFoam
dyld: Symbol not found: __ZTIN4Foam18cyclicAMIPolyPatchE
Referenced from: /Volumes/OpenFOAMv2.1/OpenFOAM-2.1.0/platforms/darwinIntel64GccDPOpt/bin/./reactingParcelFoam
Expected in: /Users/username/OpenFOAM/OpenFOAM-2.0.x/platforms/darwinIntel64Gcc45DPOpt/lib/libmeshTools.dylib
in /Volumes/OpenFOAMv2.1/OpenFOAM-2.1.0/platforms/darwinIntel64GccDPOpt/bin/./reactingParcelFoam

The lines cited above from compilation are just an example, there are a lot of other entries like that.
I also checked the ulimit, it is set to unlimited. In addition, the rights are set correct as far as I know, too. It is 755 or drwxr-xr-x right now.

So I do not understand why I got these problems, but I will give it another try with a newer compiler today.

Thanks for your help. Please let me know if you have another idea.

Cheers,

Michael

gschaider · January 19, 2012, 20:23

Quote:

Originally Posted by lithos

Ok. It does work now. You were totally right with the ulimit. Just typing ulimit on two different macs give back unlimited. But ulimit -n gives back 256. So I changed it to ulimit -n 1024 and it works very fine. Thanks again

Sorry about the ulimit. I have it in my bashrc since way back ... I don't know when. So it never crossed my mind to mention it (I tend to forget problems I solved). Another point why I'm NOT the person most qualified to describe the procedure to install OF on a Mac: I don't start from a clean slate.

So instead of thanking me for the patches (which happened I think 3 times in this thread) it would be better if someone who started with a clean slate (and still has a clear memory) writes down the steps he had to do to make it work (there is really no more to it) and then we can call it "the definite guide to installing OF on a Mac" (and throw away all the outdated Wiki-pages). Don't get me wrong. I appreciate the thank-yous but I mostly do these patches because they make life easier for me. One of the joys of OpenSource is publishing something usable and watching people making it better (than one could have done it himself). And documentation is part of this

Bernhard

Sorry for the rant

lithos · January 20, 2012, 08:43

Nothing to be sorry about. I will take care of this task this weekend. Btw, have a nice one.

Quote:

Originally Posted by gschaider

Sorry about the ulimit. I have it in my bashrc since way back ... I don't know when. So it never crossed my mind to mention it (I tend to forget problems I solved). Another point why I'm NOT the person most qualified to describe the procedure to install OF on a Mac: I don't start from a clean slate.

So instead of thanking me for the patches (which happened I think 3 times in this thread) it would be better if someone who started with a clean slate (and still has a clear memory) writes down the steps he had to do to make it work (there is really no more to it) and then we can call it "the definite guide to installing OF on a Mac" (and throw away all the outdated Wiki-pages). Don't get me wrong. I appreciate the thank-yous but I mostly do these patches because they make life easier for me. One of the joys of OpenSource is publishing something usable and watching people making it better (than one could have done it himself). And documentation is part of this

Bernhard

Sorry for the rant

January 4, 2012, 17:58		#4
wyldckat Retired Super Moderator Bruno Santos Join Date: Mar 2009 Location: Lisbon, Portugal Posts: 10,982 Blog Entries: 45 Rep Power: 128	Greetings to all! @Eric: don't worry about that, Allwmake in the "ThirdParty-2.1.0" folder will fix the issue on its own @Bernhard: The following last lines in the ThirdParty patch can be removed: Code: diff --git a/scotch_5.1.11/src/Makefile.inc b/scotch_5.1.11/src/Makefile.inc --- a/scotch_5.1.11/src/Makefile.inc +++ b/scotch_5.1.11/src/Makefile.inc @@ -1,1 +1,1 @@ -../../etc/wmakeFiles/scotch/Makefile.inc.i686_pc_linux2.shlib-OpenFOAM-64 \ No newline at end of file +../../etc/wmakeFiles/scotch/Makefile.inc.i686_mac_darwin.shlib-OpenFOAM \ No newline at end of file Look mom, no Mac! Best regards, Bruno luckycfd likes this. __________________ OpenFOAM: FAQ \| Getting started Forum: How to get help, to post code/output and forum guide Read this before sending me PM

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Extend Project 1.6-ext Binary Release for Mac OS X	hjasak	OpenFOAM Announcements from Other Sources	26	November 5, 2013 17:50
Openfoam mac: Compiling custom libraries	atareen64	OpenFOAM	3	April 14, 2011 12:01
OpenFOAM-1.6 on Mac OS X 10.6.1	elvisjohndowson	OpenFOAM	6	October 21, 2009 16:45
Mac Simple Install Request or Processing Assistance Help	sjohnson	OpenFOAM Installation	4	December 12, 2008 08:46
MAC + SOLA for free surface	T	Main CFD Forum	1	April 11, 2001 14:43

January 3, 2012, 13:27		#2
norman1981 Member Norman Del Puppo Join Date: Mar 2009 Location: Hinwil, CH Posts: 57 Rep Power: 17	Thank you, it worked well for me! Regards Norman

January 4, 2012, 17:41		#3
egp Senior Member Eric Paterson Join Date: Mar 2009 Location: Blacksburg, VA Posts: 197 Blog Entries: 1 Rep Power: 18	Hi Bernhard, Worked like a charm. OF 1.9 is running on desktop iMac. Thanks! However, the ThirdParty patch grumbled about scotch, Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file scotch_5.1.11/src/Makefile.inc.rej Makefile.inc.rej [16:36:38][egp@wtmac:ThirdParty-2.1.x]513$ more scotch_5.1.11/src/Makefile.inc.rej ************* * 1 **** - ../../etc/wmakeFiles/scotch/Makefile.inc.i686_pc_linux2.shlib-OpenFOAM-64--- 1 ---- + ../../etc/wmakeFiles/scotch/Makefile.inc.i686_mac_darwin.shlib-OpenFOAM

January 19, 2012, 09:07		#17
lithos New Member Michael Join Date: Dec 2011 Location: Geneva Posts: 28 Rep Power: 14	Dear both, the file reactingParcelFoam is there, but it does not work: ./reactingParcelFoam dyld: Symbol not found: __ZTIN4Foam18cyclicAMIPolyPatchE Referenced from: /Volumes/OpenFOAMv2.1/OpenFOAM-2.1.0/platforms/darwinIntel64GccDPOpt/bin/./reactingParcelFoam Expected in: /Users/username/OpenFOAM/OpenFOAM-2.0.x/platforms/darwinIntel64Gcc45DPOpt/lib/libmeshTools.dylib in /Volumes/OpenFOAMv2.1/OpenFOAM-2.1.0/platforms/darwinIntel64GccDPOpt/bin/./reactingParcelFoam The lines cited above from compilation are just an example, there are a lot of other entries like that. I also checked the ulimit, it is set to unlimited. In addition, the rights are set correct as far as I know, too. It is 755 or drwxr-xr-x right now. So I do not understand why I got these problems, but I will give it another try with a newer compiler today. Thanks for your help. Please let me know if you have another idea. Cheers, Michael