OF 1.9 (aka OF 2.1) on Mac OS X
 

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

Thank you, it worked well for me!

Regards

Norman

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

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

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 :

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

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.

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

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

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.

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?

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

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

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

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