[OpenFOAM.org] Patches to compile OpenFOAM 2.2 on Mac OS X

gschaider · November 9, 2013, 20:32

Quote:

Originally Posted by Alhasan

Hello ppl,

I followed http://www.optimulation.com/2013/03/...n-lion-10-8-3/
the video on the above link to install openFOAM on mac.

- surfaceaFeatureExtract (is not working - it is very important for me)
so any suggestion how to get this working
- ParaView is not working ( probably think i have install new version ?)

Kind Regards,
Hasan K.J

surfaceFeatureExtract: there is an issue with different versions of CGAL and it was discussed here on the forum. Please look for CGAL … I vaguely remember that there is already a patch for that

Paraview: How is it not working?

Alhasan · November 9, 2013, 20:42

Hey Bernhard

cd $FOAM_UTILITIES/postProcessing/graphics/PV3Readers
./Allwclean
./Allwmake

when i do that

ERROR: ParaView not found in /Users/hasan_blackspider/OpenFOAM/ThirdParty-2.2.0/platforms/darwinIntel64Gcc/paraview-3.12.0

I dont know where is that file paraview-3.12.0

Thanks,
Hasan

wyldckat · November 10, 2013, 04:29

Greetings to all!

@Hasan:

Quote:

Originally Posted by Alhasan

I dont know where is that file paraview-3.12.0

Please follow these instructions: http://openfoamwiki.net/index.php/In...using_ParaView

Best regards,
Bruno

rdbisme · November 12, 2013, 20:33

This is crazy. I'm following the same passages done a week ago with the same Mac Book Pro (and they worked before) and I'm getting errors never met before:

Code:

-fPIC -Ddarwin -c $SOURCE -o Make/darwinIntel64Gcc46DPOpt/yPlusRASFunctionObject.o
ld: library not found for -lfvOptions
collect2: ld returned 1 exit status
make: *** [/Users/rubendibattista/OpenFOAM/OpenFOAM-2.2.2/platforms/darwinIntel64Gcc46DPOpt/lib/libutilityFunctionObjects.dylib] Error 1

It seems that -lfvOptions library is not builT. What could that be?

Code:

wmake libso fvOptions
darwinIntel64Gcc46DPOpt/options:23: *** missing separator.  Stop.
wmake error: file 'Make/darwinIntel64Gcc46DPOpt/objectFiles' could not be created in /Users/rubendibattista/OpenFOAM/OpenFOAM-2.2.2/src/fvOptions

rdbisme · November 12, 2013, 22:57

Quote:

Originally Posted by tidusuper91

This is crazy. I'm following the same passages done a week ago with the same Mac Book Pro (and they worked before) and I'm getting errors never met before:

Code:

-fPIC -Ddarwin -c $SOURCE -o Make/darwinIntel64Gcc46DPOpt/yPlusRASFunctionObject.o
ld: library not found for -lfvOptions
collect2: ld returned 1 exit status
make: *** [/Users/rubendibattista/OpenFOAM/OpenFOAM-2.2.2/platforms/darwinIntel64Gcc46DPOpt/lib/libutilityFunctionObjects.dylib] Error 1

It seems that -lfvOptions library is not builT. What could that be?

Code:

wmake libso fvOptions
darwinIntel64Gcc46DPOpt/options:23: *** missing separator.  Stop.
wmake error: file 'Make/darwinIntel64Gcc46DPOpt/objectFiles' could not be created in /Users/rubendibattista/OpenFOAM/OpenFOAM-2.2.2/src/fvOptions

Ok solved.
In

Code:

(OpenFOAM Dir)/src/fvOptions/Make/options

after the first block

Code:

EXE_INC = \
    -I$(LIB_SRC)/finiteVolume/lnInclude \
    -I$(LIB_SRC)/meshTools/lnInclude \
    -I$(LIB_SRC)/sampling/lnInclude \
    -I$(LIB_SRC)/thermophysicalModels/solidThermo/lnInclude \
    -I$(LIB_SRC)/thermophysicalModels/basic/lnInclude \
    -I$(LIB_SRC)/thermophysicalModels/specie/lnInclude \
    -I$(LIB_SRC)/turbulenceModels/compressible/turbulenceModel/lnInclude \
    -I$(LIB_SRC)/turbulenceModels

There were two newlines instead of one (Just God knows why... )

rdbisme · November 15, 2013, 12:12

I've just written a wiki for the installation as I did on my MacBook pro Mid 2010.

http://openfoamwiki.net/index.php/In...OpenFOAM_2.2.2

As I'm not native english speaker if someone would correct/improve the clearness it would be really appreciated.

Hope this will help someone.

hewei · November 21, 2013, 04:44

Hello Everyone,
After I finish the installation of OpenFOAM-v2.2.2, I can not copy files from this computer or copy files to this computer via ssh, it tell me that:

Seems you're not using MacPorts. This is currently not supported/tested. Find this line in 'etc/config/settings.sh', modify it accordingly and send patches to Bernhard

but i can use this computer copy files from other machines by ssh. I don't want to eject openfoam to make scp works, so what should I do? thanks

wei

gschaider · November 22, 2013, 14:11

Quote:

Originally Posted by hewei

Hello Everyone,
After I finish the installation of OpenFOAM-v2.2.2, I can not copy files from this computer or copy files to this computer via ssh, it tell me that:

Seems you're not using MacPorts. This is currently not supported/tested. Find this line in 'etc/config/settings.sh', modify it accordingly and send patches to Bernhard

but i can use this computer copy files from other machines by ssh. I don't want to eject openfoam to make scp works, so what should I do? thanks

wei

Seems like you've added etc/basrc to your .bashrc and the output of it breaks login via ssh.

karlvirgil · November 22, 2013, 17:32

I have installed OpenFOAM-2.2.x on OS 10.9 (Mavericks). Everything installed fine, and serial openFoam jobs run fine. However, parallel jobs don't run. They stall upon initialization. They don't crash or output any error messages. I've figured out that they all stall on the MPI::Init() call. I am using the macports version of openmpi:
openmpi @1.7.3_0+gcc48 (active) platform='darwin 13' archs='x86_64'

Has anyone experienced similar issues upon upgrading to Mac OS 10.9?

Karl

gschaider · November 24, 2013, 15:54

Quote:

Originally Posted by karlvirgil

I have installed OpenFOAM-2.2.x on OS 10.9 (Mavericks). Everything installed fine, and serial openFoam jobs run fine. However, parallel jobs don't run. They stall upon initialization. They don't crash or output any error messages. I've figured out that they all stall on the MPI::Init() call. I am using the macports version of openmpi:
openmpi @1.7.3_0+gcc48 (active) platform='darwin 13' archs='x86_64'

Has anyone experienced similar issues upon upgrading to Mac OS 10.9?

Karl

Can't help you here as I haven't upgrade to Mavericks yet (and I will postpone this for a couple of weeks).

Just one question: have you tried running a non-OpenFOAM MPI-program (something like the one here http://stackoverflow.com/questions/1...-not-compiling) to find out whether this is a problem with OpenMPI in general or just the way OpenFOAM is calling it?

laz0r_viking · November 26, 2013, 10:54

Quote:

Originally Posted by tidusuper91

Ok solved.
In

Code:

(OpenFOAM Dir)/src/fvOptions/Make/options

after the first block

Code:

EXE_INC = \
    -I$(LIB_SRC)/finiteVolume/lnInclude \
    -I$(LIB_SRC)/meshTools/lnInclude \
    -I$(LIB_SRC)/sampling/lnInclude \
    -I$(LIB_SRC)/thermophysicalModels/solidThermo/lnInclude \
    -I$(LIB_SRC)/thermophysicalModels/basic/lnInclude \
    -I$(LIB_SRC)/thermophysicalModels/specie/lnInclude \
    -I$(LIB_SRC)/turbulenceModels/compressible/turbulenceModel/lnInclude \
    -I$(LIB_SRC)/turbulenceModels

There were two newlines instead of one (Just God knows why... )

Was your only solution to delete that extra line?

I'm receiving the same error which is preventing the program to build:

Code:

ld: library not found for -lfvOptions

When I go and try to re-build fvOptions, I get

Code:

$ wmake libso fvOptions
darwinIntel64Gcc46DPOpt/options:22: *** missing separator.  Stop.
wmake error: file 'Make/darwinIntel64Gcc46DPOpt/objectFiles' could not be created in /Users/Paul/OpenFOAM/OpenFOAM-2.2.2/src/fvOptions

The problem is that there doesn't seem to be anything wrong with darwinIntel64Gcc46DPOpt/options .

I'm on OS X 10.9 Mavericks, Intel Core i5, and following the Installation/Mac OS/OpenFOAM 2.2.2 tutorial line-for-line (super helpful, so far!).

This is my first time building on OS X -- all previous builds were on ArchLinux, Ubuntu, etc. I'm up for the challenge!

LV

gschaider · November 26, 2013, 13:13

Quote:

Originally Posted by laz0r_viking

Was your only solution to delete that extra line?

I'm receiving the same error which is preventing the program to build:

Code:

ld: library not found for -lfvOptions

When I go and try to re-build fvOptions, I get

Code:

$ wmake libso fvOptions
darwinIntel64Gcc46DPOpt/options:22: *** missing separator.  Stop.
wmake error: file 'Make/darwinIntel64Gcc46DPOpt/objectFiles' could not be created in /Users/Paul/OpenFOAM/OpenFOAM-2.2.2/src/fvOptions

The problem is that there doesn't seem to be anything wrong with darwinIntel64Gcc46DPOpt/options .

I'm on OS X 10.9 Mavericks, Intel Core i5, and following the Installation/Mac OS/OpenFOAM 2.2.2 tutorial line-for-line (super helpful, so far!).

This is my first time building on OS X -- all previous builds were on ArchLinux, Ubuntu, etc. I'm up for the challenge!

LV

Have a look at the Make/options of fvOptions. There probably is a line

Code:

/*-lsolidThermo*/ \

in there that throws the preprocessor off the horse. Try deleting that line and recompiling the library

laz0r_viking · November 26, 2013, 16:42

Quote:

Originally Posted by gschaider

Have a look at the Make/options of fvOptions. There probably is a line

Code:

/*-lsolidThermo*/ \

in there that throws the preprocessor off the horse. Try deleting that line and recompiling the library

That worked, thank you. Except I didn't delete the line but rather enable the -lsolidThermo flag. Not sure if I'll pay for this later.

Cheers

karlvirgil · November 26, 2013, 16:57

I have narrowed the problem down to an openmpi problem. It doesn't seem to be OpenFOAM related. I've been able to compile a simple hello world test case, but it will not run in parallel. It gets stuck in MPI::Init(). I've tried installing openmpi myself (not using macports) and I get the same problem. openmpi compiles fine, but the examples all get stuck in MPI::Init(). I was able to get mpich to compile from source, and with that the mpi example cases all work fine.

rdbisme · November 27, 2013, 04:10

Quote:

Originally Posted by laz0r_viking

Was your only solution to delete that extra line?

Yes. Just removing that newline everything went well o.O

Quote:

Originally Posted by laz0r_viking

I'm receiving the same error which is preventing the program to build:

Code:

ld: library not found for -lfvOptions

When I go and try to re-build fvOptions, I get

Code:

$ wmake libso fvOptions
darwinIntel64Gcc46DPOpt/options:22: *** missing separator.  Stop.
wmake error: file 'Make/darwinIntel64Gcc46DPOpt/objectFiles' could not be created in /Users/Paul/OpenFOAM/OpenFOAM-2.2.2/src/fvOptions

The problem is that there doesn't seem to be anything wrong with darwinIntel64Gcc46DPOpt/options .

I'm on OS X 10.9 Mavericks, Intel Core i5, and following the Installation/Mac OS/OpenFOAM 2.2.2 tutorial line-for-line (super helpful, so far!).

This is my first time building on OS X -- all previous builds were on ArchLinux, Ubuntu, etc. I'm up for the challenge!

LV

Anyway glad to know you solved...

315234 · November 28, 2013, 14:03

gschaider,

Firstly, thank you for these patches, they have saved me a lot of time.

You mention to submit patches to you if we come up with improvements. However, this is a little difficult with the current system. For one, it is difficult to find the latest version of the patch. It is difficult for people to contribute by sending patches back and forth. It is also difficult to see what changes are made over time.

Would it be possible for you to create a fork of the official 2.2.x branch on GitHub and apply your mac patches? This would offer several advantages:

A central repository which is guaranteed to have the latest version of the patch
People could easily contribute by forking the project and submitting pull requests
The patches can be kept up to date with the latest OpenFOAM release by merging with the official branch
None of the difficulties caused by manually applying the patches
The entire history of changes to the patches would be available
It would be easier to understand the patches when viewed through GitHub's online tools
It would still be possible to generate a single patch file for application to an OpenFOAM source tree

Let me know what you think of this suggestion. I would be happy to do it myself if you would rather not deal with the management of a public repository.

gschaider · November 28, 2013, 20:29

Quote:

Originally Posted by 315234

gschaider,

Firstly, thank you for these patches, they have saved me a lot of time.

You mention to submit patches to you if we come up with improvements. However, this is a little difficult with the current system. For one, it is difficult to find the latest version of the patch. It is difficult for people to contribute by sending patches back and forth. It is also difficult to see what changes are made over time.

Would it be possible for you to create a fork of the official 2.2.x branch on GitHub and apply your mac patches? This would offer several advantages:

A central repository which is guaranteed to have the latest version of the patch
People could easily contribute by forking the project and submitting pull requests
The patches can be kept up to date with the latest OpenFOAM release by merging with the official branch
None of the difficulties caused by manually applying the patches
The entire history of changes to the patches would be available
It would be easier to understand the patches when viewed through GitHub's online tools
It would still be possible to generate a single patch file for application to an OpenFOAM source tree

Let me know what you think of this suggestion. I would be happy to do it myself if you would rather not deal with the management of a public repository.

I thought about this, I understand your points but currently never took the step.

Let me explain you how I currently do this: when a new release comes out and the git-repository comes online I pull it into a mercurial-repository. In that I initiate a patch queue (http://hgbook.red-bean.com/read/mana...al-queues.html) then one by one I pull over the patches from the last release and adapt them. That are the patches I publish. (Similar thing is done for the ThirdParty-stuff. With the extension that I have to check the sources into a local repo so that I can track the necessary changes)

I have a number of reasons for this approach:
- as in their wisdom OpenCFD start a new repository for every release there is no continuity in the history. This means that with the next release all the changes done would have to be "untangled" from the old repository and applied to the new repository. You'll probably end up producing patches and reapplying them. I think the current approach is less messy (and you won't forget any commits from the old repo). "the entire history of the patch" (to quote you) is gone anyway
- for the ThirdParty-Stuff you'd have to initiate a ThirdParty-Repository with all the sources (the ones on github only have the scripts - which is fine) just to apply the few changes that are necessary there (and the necessary changes are getting fewer every time)
- OpenCFD has a very strong opinion about Mac OS X (see http://www.openfoam.com/legal/open-source.php). Which is fine. But it means that one of the main advantages on GitHub "Forking" is no use as a pull request will not be answered.

It boils down to (I quote from the patch-queue-link I gave above): "You have an “upstream” source tree that you can't change; you need to make some local changes on top of the upstream tree; and you'd like to be able to keep those changes separate, so that you can apply them to newer versions of the upstream source" In that situation doing a classic pull/branch/modify is more work. With the patch queues working is like on a regular DVCS except that committing is a little different.

I understand the problem with getting the right patches and applying them and thought about distributing them differently. The one reason was that it takes time and apart from my other work I have two projects (swak and PyFoam) that take up enough time and none of the solutions was convincing enough to start it:
- start a new repository and apply the patch there (basically what you suggested). As this wouldn't be my main work repository (for a number of reasons) it would be worse than the current situation: it would get very rarely (if ever) get merged against newer version of the upstream. That would leave people with an outdated OF-version
- publish the sub-repository of the patch-queue. As much as I think that mercurial is more elegant and flexible than git I don't want to force it onto people (part of the reason is laziness: then I'd have to explain it to people)
- put the patches as files into the SVN at openfoam-extend. That solves the problem "which is the current patch"

Side note about github: the problem with that offering is that THEY force their DVCS onto you. Which I wouldn't mind if it wasn't git. Git is the MS Windows of the DVCS. There are more elegant (local/remote/tracking-branch vs "repository is one tree of commits. Keep it simple") and flexible ("put your syntactic sugar onto the tree of commits with extensions") systems out there. But people use it because "everyone uses it" (or "Linus wrote it") and they haven't looked at the alternatives (just like Windows). One sure sign of the superiority of mercurial is that (with a plugin) a mercurial repository can pull and push to a git-repository. Haven't seen it the other way round. So if necessary I pull from GitHub but if I have to start something new I do it at BitBucket (they give me the choice between Git and Mercurial). Or Sourceforge (not as elegant but they offer a lot of stuff GitHub doesn't. Plus OpenFOAM-extend is there). Ah. And the "Fork / Pull-Request"-thing is only Web-2.0-sugar on what is possible with pure git/mercurial/whatever-repositories: mail saying "this is the URL of my repository I cloned from you. Could you pull and consider it?"

OK. That was they reason why I'm not doing it. This shouldn't discourage you. I probably won't use it for development of the patches (no offense: I explained above that it would make the process more complicated for me). If it turns out that the new MacPatchRepository is faster at adapting to new releases or has features that my patch doesn't have I might consider using it: my ego can stand it if I'm no longer "the guy who does the Mac-patches"

wyldckat · November 30, 2013, 09:02

Greetings to all!

@Ruben:

Quote:

Originally Posted by tidusuper91

I've just written a wiki for the installation as I did on my MacBook pro Mid 2010.

http://openfoamwiki.net/index.php/In...OpenFOAM_2.2.2

As I'm not native english speaker if someone would correct/improve the clearness it would be really appreciated.

Done! I've reviewed, slightly re-worded some phrases and formatted a bit more the flow of the text!
Many thanks for taking the time to write this wiki page!

@Bernhard: Many thanks for the detailed explanation on how you handle the patches. I had no idea that Mercurial had such a patch-assisting methodology.

@315234: I've also thought of this myself, but I have not taken any steps forward on this because I don't have a Mac. Nonetheless, if you have the ability to handle the repository management and double-checking if it still builds on a Mac whenever a git pull is done from the upstream repository, I support the idea that you go forward with such an effort with your own Github account. Github is able to have repositories transferred to organization accounts later on, in case a dedicated project is brought to light to support your repositories.

By the way, Michael Wild had done something like this a long time ago for OpenFOAM 1.7.x: https://github.com/themiwi/OpenFOAM-1.7.x-OSX

Best regards,
Bruno

gschaider · December 1, 2013, 07:40

Quote:

Originally Posted by wyldckat

@Bernhard: Many thanks for the detailed explanation on how you handle the patches. I had no idea that Mercurial had such a patch-assisting methodology.

To be fair: I hear that there is something similar for git (guilt or quilt or so) but the mercurial-patch queues integrate seamlessly into mercurial due to the extension-system

rdbisme · December 4, 2013, 05:33

Quote:

Originally Posted by wyldckat

Greetings to all!

@Ruben:

Done! I've reviewed, slightly re-worded some phrases and formatted a bit more the flow of the text!
Many thanks for taking the time to write this wiki page!

Thanks to you for your help.

November 15, 2013, 12:12		#86
rdbisme Senior Member Ruben Di Battista Join Date: May 2013 Location: Paris Posts: 137 Rep Power: 13	I've just written a wiki for the installation as I did on my MacBook pro Mid 2010. http://openfoamwiki.net/index.php/In...OpenFOAM_2.2.2 As I'm not native english speaker if someone would correct/improve the clearness it would be really appreciated. Hope this will help someone. wyldckat likes this.

November 21, 2013, 04:44	Conflict with command scp and OpenFOAM	#87
hewei Member Join Date: May 2010 Posts: 74 Rep Power: 16	Hello Everyone, After I finish the installation of OpenFOAM-v2.2.2, I can not copy files from this computer or copy files to this computer via ssh, it tell me that: Seems you're not using MacPorts. This is currently not supported/tested. Find this line in 'etc/config/settings.sh', modify it accordingly and send patches to Bernhard but i can use this computer copy files from other machines by ssh. I don't want to eject openfoam to make scp works, so what should I do? thanks wei

November 22, 2013, 17:32	Mac OS 10.9, OpenFOAM-2.2.x install	#89
karlvirgil New Member Join Date: Jul 2009 Location: Wrentham, MA Posts: 9 Rep Power: 17	I have installed OpenFOAM-2.2.x on OS 10.9 (Mavericks). Everything installed fine, and serial openFoam jobs run fine. However, parallel jobs don't run. They stall upon initialization. They don't crash or output any error messages. I've figured out that they all stall on the MPI::Init() call. I am using the macports version of openmpi: openmpi @1.7.3_0+gcc48 (active) platform='darwin 13' archs='x86_64' Has anyone experienced similar issues upon upgrading to Mac OS 10.9? Karl

November 28, 2013, 14:03	Move to GitHub?	#96
315234 New Member Join Date: Feb 2012 Posts: 2 Rep Power: 0	gschaider, Firstly, thank you for these patches, they have saved me a lot of time. You mention to submit patches to you if we come up with improvements. However, this is a little difficult with the current system. For one, it is difficult to find the latest version of the patch. It is difficult for people to contribute by sending patches back and forth. It is also difficult to see what changes are made over time. Would it be possible for you to create a fork of the official 2.2.x branch on GitHub and apply your mac patches? This would offer several advantages: A central repository which is guaranteed to have the latest version of the patch People could easily contribute by forking the project and submitting pull requests The patches can be kept up to date with the latest OpenFOAM release by merging with the official branch None of the difficulties caused by manually applying the patches The entire history of changes to the patches would be available It would be easier to understand the patches when viewed through GitHub's online tools It would still be possible to generate a single patch file for application to an OpenFOAM source tree Let me know what you think of this suggestion. I would be happy to do it myself if you would rather not deal with the management of a public repository.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Getting Started with OpenFOAM	wyldckat	OpenFOAM	26	June 21, 2024 07:54
OpenFOAM course for beginners	Jibran	OpenFOAM Announcements from Other Sources	2	November 4, 2019 09:51
OpenFOAM v3.0+ ??	SBusch	OpenFOAM	22	December 26, 2016 15:24
[OpenFOAM.org] A Mac OS X of23x Development Environment Using Docker	rt08	OpenFOAM Installation	1	February 28, 2016 20:00
OpenFOAM Training, London, Chicago, Munich, Sep-Oct 2015	cfd.direct	OpenFOAM Announcements from Other Sources	2	August 31, 2015 14:36

November 9, 2013, 20:42		#82
Alhasan Senior Member Hasan K.J. Join Date: Dec 2011 Location: Bristol, United Kingdom Posts: 200 Rep Power: 15	Hey Bernhard cd $FOAM_UTILITIES/postProcessing/graphics/PV3Readers ./Allwclean ./Allwmake when i do that ERROR: ParaView not found in /Users/hasan_blackspider/OpenFOAM/ThirdParty-2.2.0/platforms/darwinIntel64Gcc/paraview-3.12.0 I dont know where is that file paraview-3.12.0 Thanks, Hasan

November 26, 2013, 16:57		#94
karlvirgil New Member Join Date: Jul 2009 Location: Wrentham, MA Posts: 9 Rep Power: 17	I have narrowed the problem down to an openmpi problem. It doesn't seem to be OpenFOAM related. I've been able to compile a simple hello world test case, but it will not run in parallel. It gets stuck in MPI::Init(). I've tried installing openmpi myself (not using macports) and I get the same problem. openmpi compiles fine, but the examples all get stuck in MPI::Init(). I was able to get mpich to compile from source, and with that the mpi example cases all work fine.