[ajmas]

I am going to see if we can get some of these Mac related changes merged into the main repository, on the condition they don't break the main Linux build.

[Petru]

Originally Posted by ajmas

Quote:
Originally Posted by ajmas View Post
Current status update on my efforts:
- https://github.com/ajmas/OpenFOAM-2.3.x master branch includes most of the changes available in this thread
- I have created a build script, attached to this post that should make building much easier. Doing the following:
-- Creating and mounting case-sensitive HFS+ disk image
-- Getting the necessary MacPorts (if you use another tool, please contribute changes)
-- Cloning the git repository (uses mine, since it is already patched)
-- Configuring bashrc
-- initiating the build
-- Ensuring the build is outputted to log
For anyone using MacPorts be sure to check your PATH environment variable. Be sure to put /opt/local/bin at the start, to avoid MacOS X versions of commands taking precedence.

I found this due issues resulting from the using of the version of flex at /usr/bin/flex. The MacOS X default version will fail in certain cases.

I have also now put the script for the build script on GitHub: https://github.com/ajmas/scripts-et-...sx-macports.sh

And with all this it all builds

Hi,
Thank you for your help.
It is finally working!!!!!
After some hours of building, the installation is now complete without any error...now I have just a question:
Is the installation permanent?
I mean, now I think everything is inside the volume, if I remove it, what is going to happen? Will I lose everything (the installation)? How can I make it permanent?
Sorry but I am not very good in this kind of things.
Thank you again,
it was very useful, specially for who is not good enough as me!!!

All the best,
Paolo

[ajmas]

Originally Posted by Petru

Hi,
Thank you for your help.
It is finally working!!!!!
After some hours of building, the installation is now complete without any error...now I have just a question:
Is the installation permanent?
I mean, now I think everything is inside the volume, if I remove it, what is going to happen? Will I lose everything (the installation)? How can I make it permanent?
Sorry but I am not very good in this kind of things.
Thank you again,
it was very useful, specially for who is not good enough as me!!!

All the best,
Paolo

Unmounting the drive will not delete the data. Just remount the drive any time you need to use OpenFOAM. Just be sure to use a bash prompt at the command line and source the etc/bashrc provided with OpenFOAM. BTW from a bash prompt you can source the file by (that is a full-stop at the start):

. [path to OpenFOAM]/etc/bashrc

Of course be sure to replace '[path to OpenFOAM]' with the appropriate path. You can move the disk image to where you want to keep it, but when mounted the volume path should always be the same.

[maCrobo]

Originally Posted by ajmas

Current status update on my efforts:
- https://github.com/ajmas/OpenFOAM-2.3.x master branch includes most of the changes available in this thread
- I have created a build script, attached to this post that should make building much easier. Doing the following:
-- Creating and mounting case-sensitive HFS+ disk image
-- Getting the necessary MacPorts (if you use another tool, please contribute changes)
-- Cloning the git repository (uses mine, since it is already patched)
-- Configuring bashrc
-- initiating the build
-- Ensuring the build is outputted to log

Please let me know if this helps you and please provide any pull-requests or change suggestions.

Note, I still waiting for my current build to finish, so will see if it is successful.

Thanks for the effort. What patches are you using? I'm asking that because it appears that defining paraview as a function avoids some issues with paraFoam. In fact, the user Alexejm did that in his patch and it seems pretty easy and quick a change. I'm advising it because lately on 3 different macs (1 with Mavericks, 2 with Yosemite) I met the same issue: everything installed smoothly, but paraFoam calls gives an error, which seems related to the alias definition used in Bernhard Gschaider's patch (using a function definition solves the problem).

[ajmas]

Originally Posted by maCrobo

Thanks for the effort. What patches are you using? I'm asking that because it appears that defining paraview as a function avoids some issues with paraFoam. In fact, the user Alexejm did that in his patch and it seems pretty easy and quick a change. I'm advising it because lately on 3 different macs (1 with Mavericks, 2 with Yosemite) I met the same issue: everything installed smoothly, but paraFoam calls gives an error, which seems related to the alias definition used in Bernhard Gschaider's patch (using a function definition solves the problem).

I used a number of patches from the thread. You can see the source code in GitHub.

I encountered some issue using the paraFoam command too, since paraview.app doesn't support the .openFoam extension. If anyone has this working I'll integrate this into my fork.

[maCrobo]

Originally Posted by ajmas

I used a number of patches from the thread. You can see the source code in GitHub.

I encountered some issue using the paraFoam command too, since paraview.app doesn't support the .openFoam extension. If anyone has this working I'll integrate this into my fork.

The paraview.sh file can be changed so that from line 147 to 161 it looks like the following code.

147 if [ $WM_ARCH_BASE=="darwin" ]
148 then
149     : ${PARAVIEW_APP_DIR:="/Applications/paraview.app"}; export PARAVIEW_APP_DIR
150     if [ -d "$PARAVIEW_APP_DIR" ]; then
151         echo "Using paraview in directory $PARAVIEW_APP_DIR"
152         paraview () {
153             $PARAVIEW_APP_DIR/Contents/MacOS/paraview "$@"
154         }
155 
156         export -f paraview
157     else
158         echo "Please install Paraview into /Applications."
159         return
160     fi
161 fi

If you look at your patch changes (etc/config/paraview.sh), you can see that you used an alias definition:

+if [ $WM_ARCH_BASE=="darwin" ]
+then
+    : ${PARAVIEW_APP_DIR:="/Applications/paraview.app"}; export PARAVIEW_APP_DIR
+    if [ -d $PARAVIEW_APP_DIR -a ! -r $ParaView_DIR ]
+    then
+	echo "Using paraview in directory $PARAVIEW_APP_DIR"
+	unset ParaView_VERSION ParaView_MAJOR ParaView_DIR
+	# needs to be an alias because if it is in the path the Python Shell does not work
+	alias paraview=$PARAVIEW_APP_DIR/Contents/MacOS/paraview
+	export PATH=$PARAVIEW_APP_DIR/Contents/bin:$PATH
+    fi
+fi
+

That's it.
I haven't tried your script yet, so I can't give feedback on that.

NB: All that was suggested to me by the user alexeym, and it proved to solve an issue I met after building OpenFoam on some Mavericks and Yosemite OS. In fact, the issue consists of getting the following answer when calling paraFoam -builtin

/Volumes/OpenFoam-v2.3.x/openfoam-mac-install/OpenFOAM-2.3.x/bin/paraFoam: line 265: paraview: command not found

[ajmas]

Thanks @maCrobo for the suggestions, I have now applied them.

Using 'paraFoam -builtin' seems to help, though should we be trying to do anything with PV4Readers (request if param is not specified)?

[maCrobo]

Originally Posted by ajmas

Thanks @maCrobo for the suggestions, I have now applied them.

Using 'paraFoam -builtin' seems to help, though should we be trying to do anything with PV4Readers (request if param is not specified)?

Hello, you should thank alexeym, not me.
As far as your doubt goes, I got the impression that those PV4Readers are used for the Linux distribution of Paraview. In fact, it seems that if you want Paraview on Linux you have to compile it, and those PV4 files are there to modify some features (i.e. some buttons and panels) and have Paraview directly handle OpenFoam file format. So, I would say we won't be needing those PV4Readers files on Mac OS (where the conditional is to say there can be something I'm missing about that).
Finally, the simple paraFoam command (without any options) doesn't work on MacOS.

[alexeym]

Hi,

Originally Posted by maCrobo

As far as your doubt goes, I got the impression that those PV4Readers are used for the Linux distribution of Paraview. In fact, it seems that if you want Paraview on Linux you have to compile it, and those PV4 files are there to modify some features (i.e. some buttons and panels) and have Paraview directly handle OpenFoam file format.

Not exactly. You can install Paraview binary package on Linux and use 'paraFoam -builtin'. Built-in OpenFOAM reader has certain problems (it does not understand uniformFixedValue boundary conditions for example) and certain advantages (it can read decomposed cases). Also you can build Paraview from sources on OS X (http://www.paraview.org/Wiki/ParaView:Build_And_Install) and after you can try to build PV4Readers. As from time to time people can not follow short OpenFOAM's installation guide, Paraview & PV4Readers build will be overkill.

Originally Posted by maCrobo

Finally, the simple paraFoam command (without any options) doesn't work on MacOS.

For paraFoam command to work without '-builtin' option, you have to patch it (or create an alias paraFoam='paraFoam -builtin' ). -builtin flag basically does the following:

# parse options
while [ "$#" -gt 0 ]
do
    case "$1" in
    ...
    -builtin)
        extension=foam
        requirePV=0
        shift
        ;;
...

You can permanently change lines above this while loop to

# reader extension
extension=foam

requirePV=0

and paraFoam will use built-in OpenFOAM reader by default.

[maCrobo]

Originally Posted by alexeym

Not exactly. You can install Paraview binary package on Linux and use 'paraFoam -builtin'. Built-in OpenFOAM reader has certain problems (it does not understand uniformFixedValue boundary conditions for example) and certain advantages (it can read decomposed cases). Also you can build Paraview from sources on OS X (http://www.paraview.org/Wiki/ParaView:Build_And_Install) and after you can try to build PV4Readers. As from time to time people can not follow short OpenFOAM's installation guide, Paraview & PV4Readers build will be overkill.

Is there a way to get rid of the uniformFixedValue "misunderstanding" ?

Would compiling paraview and PV4Readers take interesting features?

[alexeym]

Hi,

Originally Posted by maCrobo

Is there a way to get rid of the uniformFixedValue "misunderstanding" ?

I don't know any.

Would compiling paraview and PV4Readers take interesting features?

It depends on the meaning of "interesting features". As you are compiling everything yourself, it is you who controls set of features that will be in the final application bundle.

[KateEisenhower]

Originally Posted by totalart

I have successfully installed OF 2.3.0 following the instruction in Alexey Matveichev's blog. Everything's okay except snappyHexMesh. Following error occurs with SHM(I'm not running parallel).

dyld: Symbol not found: __SCOTCHbgraphbipartststratab
Referenced from: /Users/totalart/OpenFOAM/OpenFOAM-2.3.0/platforms/darwinIntel64ClangDPOpt/lib/openmpi-system/libptscotchDecomp.so
Expected in: flat namespace
in /Users/totalart/OpenFOAM/OpenFOAM-2.3.0/platforms/darwinIntel64ClangDPOpt/lib/openmpi-system/libptscotchDecomp.so
Trace/BPT trap: 5


In the Allwmake log, there was no error but warnings only. Anyone can advise what the problem is?

Many Thanks,
Young-kook

Hello everyone,

I got a very similar error when running snappyHexMesh on the motorBike tutorial:

dyld: Symbol not found: __SCOTCHbgraphbipartststratab
  Referenced from: /usr/local/opt/scotch/lib/libptscotch.dylib
  Expected in: flat namespace
 in /usr/local/opt/scotch/lib/libptscotch.dylib
Trace/BPT trap: 5

The difference is, I am not running 2.3.0, but OpenFOAM 2.3.1 with the 2.3.1 patch from here (https://github.com/mrklein/openfoam-...AM-2.3.1.patch).

Has anybody experienced this problem as well?

Originally Posted by alexeym

Hi,

well, it appeared that previous patch had more problems than I though. So here is a new patch for 2.3.0 - https://bitbucket.org/mrklein/openfo...20140421.patch.

Unfortunately, due to the problems with dynamicCode in previous patch, you need to rebuild everything. The list of bugs in previous patch that was fixed in the new one:
- mess with DYLD_LIBRARY_PATH, now I think it is finally correct
- error in Allwmake for ptscotch decomposition method (this was the reason for the error)
- error in wmake/Makefile (OpenFOAM code expected dynamic library to have extension .dylib while in Makefile it was .so, and that breaks dynamicCode functionality)
- Clang over-optimization of limited schemes that lead to FPE

I am thinking about installing OpenFOAM 2.3.0 with this updated patch. The link doesn't work anymore, unfortunately. Is this one (https://github.com/mrklein/openfoam-...AM-2.3.0.patch) the same?
And can anyone please tell me how to uninstall/remove OpenFOAM from my hard drive?

I really appreciate your help,

Kate

[alexeym]

Hi,

Originally Posted by KateEisenhower

Has anybody experienced this problem as well?

I have tried to reproduce the error you posted. OS X 10.10.2, OpenFOAM 2.3.1, patch from github. Unfortunately I was not successful. On my laptop everything runs perfectly well.

I am thinking about installing OpenFOAM 2.3.0 with this updated patch. The link doesn't work anymore, unfortunately. Is this one (https://github.com/mrklein/openfoam-...AM-2.3.0.patch) the same?

Not quite sure they are the same. I think patch on Github contains certain additional corrections.

And can anyone please tell me how to uninstall/remove OpenFOAM from my hard drive?

You can just remove (delete) disk image you have created during installation.

[KateEisenhower]

Originally Posted by alexeym

Hi,



I have tried to reproduce the error you posted. OS X 10.10.2, OpenFOAM 2.3.1, patch from github. Unfortunately I was not successful. On my laptop everything runs perfectly well.



Not quite sure they are the same. I think patch on Github contains certain additional corrections.



You can just remove (delete) disk image you have created during installation.

Thank you for the quick answer. I'll try to install again and will report afterwards. Mayhaps I did something wrong.

[KateEisenhower]

Originally Posted by alexeym

Hi,



I have tried to reproduce the error you posted. OS X 10.10.2, OpenFOAM 2.3.1, patch from github. Unfortunately I was not successful. On my laptop everything runs perfectly well.



Not quite sure they are the same. I think patch on Github contains certain additional corrections.



You can just remove (delete) disk image you have created during installation.

I reinstalled OpenFOAM 2.3.1 and had a look at the log.Allwmake file afterwards. I was quite surprised to find many warnings and "could not open file" outputs. Is this normal? It is 11.7 MB big. So unfortunately I can't upload it here.
After that, I tried the cavity tutorial and it worked fine, just for the record.
Then I performed the following steps in the motorBike directory:
1) I built the initial mesh with blockMesh and viewed it in ParaView. This worked.
2) Then I entered snappyHexMesh. I got the following output:

dyld: Symbol not found: __SCOTCHbgraphbipartststratab
  Referenced from: /usr/local/opt/scotch/lib/libptscotch.dylib
  Expected in: flat namespace
 in /usr/local/opt/scotch/lib/libptscotch.dylib
Trace/BPT trap: 5

Is this the proper way of proceeding? Does anyone know which point I am missing here?

Moreover, it strikes me that I have an "0.org" folder in the motorBike directory. Why isn't it just called "0"?

[alexeym]

Hi,

Originally Posted by KateEisenhower

I reinstalled OpenFOAM 2.3.1 and had a look at the log.Allwmake file afterwards. I was quite surprised to find many warnings and "could not open file" outputs. Is this normal? It is 11.7 MB big. So unfortunately I can't upload it here.

You can use Dropbox to share the file. You can use Github to share the file. You can use Bitbucket to share the file. Surely you will need account on one of these services. The first is user-friendly, the second and the third are developer-friendly.

dyld: Symbol not found: __SCOTCHbgraphbipartststratab
  Referenced from: /usr/local/opt/scotch/lib/libptscotch.dylib
  Expected in: flat namespace
 in /usr/local/opt/scotch/lib/libptscotch.dylib
Trace/BPT trap: 5

If you are talking about tutorials/mesh/snappyHexMesh/motorBike tutorial case, you can look inside Allrun script to see how it is intended to run. Purpose of 0.org is to keep original initial and boundary conditions files (as the name suggests). Tutorial uses potentialFoam to initialize flow, the solver will overwrite files in 0 folder. So Allrun script copies 0.org to 0 and then runs solvers.

The error is quite suspicious, can you, please, post output of the following commands ($ is shell prompt, you don't need to copy it):

$ sw_vers
$ gcc --version
$ clang --version

[KateEisenhower]

Originally Posted by alexeym

Hi,



You can use Dropbox to share the file. You can use Github to share the file. You can use Bitbucket to share the file. Surely you will need account on one of these services. The first is user-friendly, the second and the third are developer-friendly.

Here you go: https://www.dropbox.com/s/8d1x7njf4h..._copy.txt?dl=0

If you are talking about tutorials/mesh/snappyHexMesh/motorBike tutorial case, you can look inside Allrun script to see how it is intended to run. Purpose of 0.org is to keep original initial and boundary conditions files (as the name suggests). Tutorial uses potentialFoam to initialize flow, the solver will overwrite files in 0 folder. So Allrun script copies 0.org to 0 and then runs solvers.

Thank you very much for the explanation.
There was quite a missunderstanding. I was talking about the tutorials/incompressible/simpleFoam/motorBike tutorial. I will try to run the motorBike from the tutorials/mesh/snappyHexMesh/motorBike directory now and will report back to you later

The error is quite suspicious, can you, please, post output of the following commands ($ is shell prompt, you don't need to copy it):

$ sw_vers
$ gcc --version
$ clang --version

$ sw_vers

:

ProductName:	Mac OS X
ProductVersion:	10.10.2
BuildVersion:	14C1514

$ gcc --version

:

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix

$ clang --version

:

Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix

[alexeym]

Hi,

1. Warnings about missing files that is in your log are expected

Note: ignore spurious warnings about missing mpicxx.h headers

wclean mpi
wmake libso mpi
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file UOPwrite.C
could not open file omp.h for source file UOPwrite.C due to No such file or directory
could not open file ompi/mpi/cxx/pmpicxx.h for source file UOPwrite.C due to No such file or directory
...

2. In fact these tutorial cases are similar (or even identical). And you should better use Allrun script to run the case.

3. And finally I have found that currently Homebrew installs Scotch as a set of *.dylib files. Scotch of my laptop was build from sources and is a set of *.a files. I will install new Scotch version and try to release a fix for your error.

[alexeym]

@KateEisenhower

I have reproduced your error (finally) and it was really due to change in Homebrew's Scotch build process (i.e. they moved from static library to dynamic library and ptscotch now needs -lscotch during linking). Fortunately the fix is rather simple. You have two possibilities:

1. If you still have OpenFOAM installed, do the following

$ cd $HOME/OpenFOAM/OpenFOAM-2.3.1
$ curl -L https://raw.githubusercontent.com/mrklein/openfoam-os-x/master/OpenFOAM-2.3.1-scotch.patch > OpenFOAM-2.3.1-scotch.patch
$ git apply OpenFOAM-2.3.1-scotch.patch
$ cd src/parallel/decompose
$ ./Allwmake

2. If you removed OpenFOAM. Start from the beginning. Now patch is adapted for the new version of Scotch.

[KateEisenhower]

Originally Posted by alexeym

@KateEisenhower

I have reproduced your error (finally) and it was really due to change in Homebrew's Scotch build process (i.e. they moved from static library to dynamic library and ptscotch now needs -lscotch during linking). Fortunately the fix is rather simple. You have two possibilities:

1. If you still have OpenFOAM installed, do the following

$ cd $HOME/OpenFOAM/OpenFOAM-2.3.1
$ curl -L https://raw.githubusercontent.com/mrklein/openfoam-os-x/master/OpenFOAM-2.3.1-scotch.patch > OpenFOAM-2.3.1-scotch.patch
$ git apply OpenFOAM-2.3.1-scotch.patch
$ cd src/parallel/decompose
$ ./Allwmake

2. If you removed OpenFOAM. Start from the beginning. Now patch is adapted for the new version of Scotch.

Thank you! This worked. I don't get this error anymore.
However, I tried to run the motorBike tutorial by running the Allrun script. I got the following output:

kates-mbp:~ kateeisenhower$ /Users/kateeisenhower/OpenFOAM/kateeisenhower-2.3.1/run/tutorials/incompressible/simpleFoam/motorBike/Allrun ; exit;
/Users/kateeisenhower/OpenFOAM/kateeisenhower-2.3.1/run/tutorials/incompressible/simpleFoam/motorBike/Allrun: line 5: /bin/tools/RunFunctions: No such file or directory
logout

Of course I could source the RunFunctions by myself, but isn't the Allrun script supposed to do this?