CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Installation on Windows, Mac and other Unsupported Platforms (http://www.cfd-online.com/Forums/openfoam-installation-windows-mac/)
-   -   OF 1.9 (aka OF 2.1) on Mac OS X (http://www.cfd-online.com/Forums/openfoam-installation-windows-mac/95763-1-9-aka-2-1-mac-os-x.html)

gschaider January 1, 2012 17:35

OF 1.9 (aka OF 2.1) on Mac OS X
 
4 Attachment(s)
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 (Post 337909)
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 (Post 337923)
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 (Post 338138)
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 (Post 338138)
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 (Post 338252)
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 (Post 338257)
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 (Post 338277)
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 (Post 338283)
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 (Post 338319)
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 (Post 337513)
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 (Post 339874)
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 (Post 339874)
....
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 (Post 340093)
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 (Post 340165)
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 (Post 340219)
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



All times are GMT -4. The time now is 03:33.