Patches to compile OpenFOAM 2.2 on Mac OS X
 

Those of you using OpenSource for their CFD-needs, working with a Unix-like operating system but who were tempted by the slick hardware to the dubious corporation with the fruit in the logo may be interested in these patches for the latest version of OpenFOAM that allow compiling it on Mac OS X.

Those who say "How dare you use this fine OpenSource-program on these evil machines" are of course right, I feel ashamed and mumble "But they look so good, they work so fine and as long as it is not in the AppStore Apple will not profit from this"

Anyway. To the point. The patch has the same functionality as the last one for 2.1 posted here:
http://www.cfd-online.com/Forums/ope...tml#post412411
It is installed in the same way as the 2.1-patch described here: http://openfoamwiki.net/index.php/Ho...enFOAM_v21_Mac

One note: the patch is supposed to create some symbolic links in wmake/rules but instead only creates files. So replace the file darwinIntel64Gcc4X (X from {2..8}) with a symbolic link to darwinIntel64Gcc

For thirdparty-software I rely on MacPorts. For the compilation I used from MacPorts

- OpenMPI
- gcc46 (gcc47 doesn't work for me, but your milage may vary)
- boost and cgal (these are optional. If found they will be used for surfaceExtractFeatures). Usage of these is new for this patch
- ccache (optional but highly recomended)

Contents of my ../site/2.2.x/prefs.sh are:
Feel free to experiment with other compilers

The only thing used/compiled from the original OpenFOAM-Thirdparty-software currently is scotch/ptscotch (as MacPorts uses an older version here)

Have fun and put your MacBooks into brown paper bags when you go outside so that the OpenSource-police won't spot you ;)

Attachment 19669Attachment 19670

Patches to compile OpenFOAM 2.2 on Mac OS X
 

Thanks, Bernhard!

Two questions for you on this:

1.) In etc/config/settings I see that, if someone has MacPorts installed, you are resetting WM_MPLIB=MACPORTOPENMPI. This caused a hiccup in compiling for me because I have MacPorts installed, but I want to use my SYSTEMOPENMPI installed elsewhere. Perhaps there is a reason for doing this, though?

2.) Did you have any problems compiling scotch in ThirdParty? I cannot get around the following error: ld: library not found for -lrt. I am using Gcc46.

Thanks again!

Brent

No special reason. I used to use the openmpi provided by Apple as I figured that this is the easiest way for people to install it. Then Apple stopped shipping it (I think starting with 10.7) and I figured "next easiest way to install it is with MacPorts" and as the number of machines I can test the patch on is rather limited (basically only my laptop) I only supported this option. I'll modify the patch so that it is more flexible in that respect. For the time being comment it out

No. It worked for me the first time around. This looks like scotch diagnosed it to be a linux-machine (-lrt is typical for that).

Looked at the patch and it seems like I forgot to include a include for the Makefile for scotch and therefor the compilation doesn't find out that this is a Mac (I thought scotch now supports the Mac out of the box, but it seems that I applied the 2.1-patch and forgot about that one file)

Will upload modified patches ASAP

Here they come:

Attachment 19704Attachment 19705

The Third-Party-Patch now creates etc/wmakeFiles/scotch/Makefile.inc.i686_mac_darwin.shlib-OpenFOAM that is needed for scotch to compile correctly.

The other patch now adds two things if your setup differs from mine (if you don't use Macports for everything):
- if macports is not found it tells you so and which file to modify for your setup. It would be nice if people provided me with their modification. Then I can add them to the patch
- if MacPorts is used but no openmpi is found in MacPorts it defaults to OPENMPI and prints a variable that can be used to modify that behaviour.

Note: the thirdparty-patch assumes for the compilation of scotch that mpicc is called openmpicc

Great job, saves me alot of work again :)

I also feel a bit ashamed to use openfoam on mac, but only a little ;)

I try to take the catholic approach about it: confess my sins, get absolved, try to sin less, but know that I eventually will again

Or one could argue, ahem, that the patch is meant to get OpenFOAM working on Darwin, which is in theory open-source, and the hardware is thus irrelevant (read ignored).

Bernhard, fantastic job again!

P.S. Works fine with Gcc45 (it stubbornly came with openmpi from macports)

Hello!

Sourcing the bashrc gives the following output on my MacBook Pro (OS X 10.8.3)!

Can anybody comment on this?

Best regards,
MD

No.

No. Seriously: the /usr/local stuff is puzzling as the patch doesn't do anything there. Is it possible that in /usr/local you have an OpenMPI-installation (probably non-MacPorts)

About ulimit: is it possible that when adding it you entered 1O24 instead of 1024?

Thanks for replying. This is very much appreciated.

It seems that I figured out the two issues: The "/usr/local stuff" disappeared after rebooting my system. The problem with "ulimit" was due to the fact that the line had been put into the file using copy&paste. I was able to compile OF22x

Next I went on to compile the Thirdpartys:

Doing ./makeParaView gives me the error message

This error has been reported also in another Forum message in 2010 (http://www.cfd-online.com/Forums/ope...-paraview.html) but the solution proposed there () does not work for me. It is strange that WM_CC is not mentioned in the makeParaView.

Could anyone please give me a hint to fix this?

Best,
MD

Good. Maybe opening terminal might have helped as well, but it is too late to test that now (and purely academic as it works now)

If the text on the Wiki is wrong, please correct it. If it was "only" an extra character that was introduced by the paste then there is nothing that can be done about it I'm afraid.

I stopped building paraview on the Mac as I'm quite happy with the built in reader (it allows me to view decomposed cases without reconstructing them. Not sure whether PV3Reader supports that yet). That is why the patch "only" makes sure that a "official" binary that is found in the Applications-folder can be used from the command line.

If you want to compile Paraview anyway: the makeParaView-script supports you in that because it allows you to select phases:
- first run only the config-phase (which will fail as you showed above)
./makeParaView -config -no-make -no-install
- got to the directory that makeParaView created for building (somewhere in build) and start the CMake Text-Gui:
ccmake .
- the TUI will tell you about undefined stuff (like the compiler). Try to fix these until the TUI allows you to generate the necessary Makefiles (you're pretty much on your own here, but most of the problems have already been answered, usually on the Paraview-mailing-list. Google is your friend here)
- go back to the root of the ThirdParty-directory and no run the remaining phases:
./makeParaView -no-config -make -install
If you fail to specify -no-config it will overwrite all the work you did before, so be careful

I did all this (and rolled it into the patch) with older versions. I'd still do it if I had the time, but I think my time is better spent with other projects. So if you (or anyone else) fells like doing this and sharing it with the world I'd appreciate this

I am having a problem with compiling on 10.8.2

Steps I took:

1) I downloaded the lastest git version
2) applied the 20130309 patches,
3) changed the permissions on addr2line4Mac.py
4) fixed the sym links in wmake/rules
5) update site/2.1.x/prefs.sh for gcc46 and ccache
6) ./Allwmake 2>&1 | tee make.log

After trying to compile I also had to comment the changes in etc/config/settings.sh because I have macports installed for MPI and ccache but didn't install cgal or boost:

Trying to recompile I get the following errors:

Dear Bernhard:

Thank you so much for your answer.

Opening new terminals did not work, I tried that out several times without success. I am all right, however I am still a bit unclear about the various installations of OpenMPI on my system (I used MacPorts as well as another site to download them and I am not sure how all this lives side-by-side).

I decided to postpone the compilation of Paraview at a later point since I have a working version of it in the Applications folder, too. I will let you know when I get back to this in the future.

Thanks also for clarifying that the patch for the Thirdparties . I was not aware about this and I though it would only care about the scotch and the OpenMPI libraries.


Best regards,
Marco.

OK. I'll make the test more specific.

The problem is that multiphaseMixture.dep does not have the correct syntax and it all goes downhill from there. The file machine-generated so it is not the fault of the patch. Usually the cause for a corrupted dep-file is that during the generation of that file the compilation was interrupted (usually by the user pressing Ctrl-C) and the file was only partially written. Remove the file and try to compile again

It worked! Thanks!!

Dear Forum members:

I try to maintain OF2.1.1 and OF2.2.x on a MacBookPro 10.8.3.

Loading OF21 works fine and it seems that I have a fully working installation

Starting OF22 there is serious a problem and the cp command is not recognized!

So there is a issue with $PATH. This creates a problem when I compile the ThirdParty directory because Allwmake looks for cp in the paraview folder and will crash!

Can anyone comment on this, or give me a hint how to fix it?
Looking forward reading from you.
Regards,
MD

Problem seems to be that there is a cp in /Applications/paraview.app/Contents/bin ! I have no idea how it got there (I use the Kitware-binaries and thy have no cp in that folder). Is your paraview.app selfcompiled? (maybe a problem with the install-script). My installation has only 6 binaries in that folder. All starting with pv*

Usually I'd say standard-utilities in non-standard places is highly suspicious (smells like root-kit) but I guess in this case it is "just" a problem with the install scripts

Hi Bernhard:

Thanks for the post.
My paraview.app is not self-compiled and I checked three versions of ParaView on This is what I found:

• ParaView-3.98.0-Darwin-64bit has 6 files pv* in the /Applications/paraview.app/Contents/bin folder plus an additional 429 symbolic links, one of them named cp causing the problem.
• ParaView-3.98.1-Darwin-64bit has 6 files pv*in the Contents/bin folder.
• ParaView-3.14.1-Darwin-x86_64bit has 6 files pv* in the Contents/bin folder.

So I am going to delete my version of ParaView and replace it with one of the other two. … And this should resolve the problem. I hope that working with 3.98.1 is ok.

Thanks and regards,
MD

My guess is that the packager is very embarrassed about these links

Use the git version, not the tarball download
 

For new people reading this forum, I found that it may be necessary to use the git repository version, rather than the tarball download. I was getting the following error with the download.

make: *** No rule to make target `matrices/lduMatrix/lduMatrix/lduMatrix.dep', needed by `Make/darwinIntel64Gcc46DPOpt/dependencies'. Stop.
make: *** Waiting for unfinished jobs....

But if I pulling the source from git, it worked without a problem.

OS X 10.8.
gcc-4.6, openmpi, flex, bison, ccache, cgal, and boost installed from macports

1) pull the latest git version
2) applied the 20130309 patches,
3) changed the permissions on addr2line4Mac.py
4) fixed the sym links in wmake/rules
5) update etc/bashrc for gcc46 and ccache
6) ./Allwmake 2>&1 | tee make.log