[bouke]

Hi Guys,

I am trying to get OpenFOAM to run on my intel Mac. So far, I got stuck a bit on the patch command, which was ignoring directory names but I (just) figured out that I should include the p0 option (which I falsely assumed would be the default) like

patch -i OpenFOAM1.4-forMac.v1.patch -p0
(to be executed in the OpenFOAM-1.4 directory)

maybe it would be an idea to include the exact commands in the wiki page?

I'll let you know how I fare with the rest of the stuff the next few days.

Bouke

[gschaider]

Hi!

One of the problems with that patch (as I've been told) is that it creates files in a directory wmake/rules/darwin. Because this directory is not present it won't create the files and then the compilation fails. Therefor create the directory before applying the patch (I always try with --dry-run before applying for real and always use -b for backup files).

Bernhard

[bouke]

Hi,

I suppose the rules are created not in the patch but in the additional tar archive DarwinWMakeRules?

(provided it is unpacked in the OpenFOAM-1.4 directory)

[gschaider]

"the additional tar archive DarwinWMakeRules" Oops. When did that get added? I guess you're right.

Sorry. I wasn't
a) aware that I uploaded that (but the logs say so)
b) confused by a question I got by mail (where now in hindsight I can say that the tar wasn't extracted in the right place)

[bouke]

Ok, applying the patches etcetera on my Intel Mac went quite smoothly after all. One thing to remember is that since you have to install OpenFOAM on a disk image, you certainly need to edit OpenFOAM-1.4/.OpenFOAM-1.4/bashrc to change the installation directory from the default $HOME/OpenFOAM (in my case to /Volumes/OF/OpenFOAM).

My system doesn't seem to know gmake, which I solved by making a link 'gmake' to make in /usr/bin.

Compilation went quite good, wmake, src and solvers were built without errors; there are a few issues left in compilation of the utilities (which may or may not be critical):

applications/utilities/mesh/manipulation/setSet/readline-5.0, building of the GNU readline library gives an error (non-critical as setSet is built ok)

Then there is a problem in linking foamDebugSwitches:
/usr/bin/ld: can't locate file for: -lGL

and some errors building stuff in the parallelProcessing directory that I suppose are not critical.

The next step will be to pass the foamInstallationTest...

[bouke]

First hitch: I got a "conflicting installations" error for gcc from foamInstallationTest, which as I understand usually means that the binary $WM_COMPILER_DIR/bin/gcc can not be found. Even though I had the compiler where I though it should be. Turns out I named the directory "Darwin" while (you?) name the architecture "darwin".

Still three critical errors to go...

[gschaider]

Hi Bouke!

To be honest: I never used foamInstallationTest on my Mac (my usual test for "is OF working" is: try blockMesh on damBreak, try interFoam, try paraFoam on the results. foamInstallationTest is only an indication: Why is it failing? If that works I consider the OF-installation to be functional)

The problems in your previous posting I will have a look at: maybe I overlooked them in my build

Bernhard

[tufty]

Hi Bouke.

Just been through the 1.4 compilation nightmare myself, and I'm about to go through it again due to a slight "fat fingers" moment resulting in me blowing away most of the installation <sigh>.

I built with mico 2.3.11 and Paraview installed in /usr/local, which caused a few "issues", but otherwise, I had the same problems as you.

If you have readline installed already, which it should be, to be honest, but I forget what comes "stock" with OSX. You can get rid of the setSet issues by editing Allwmake in the setSet directory to set the correct path, and simply blowing away the bit that tries to build readline

For foamDebugSwitches I added a -L/usr/X11R6/lib before -lGL in options

The parallel processing stuff I've not fixed, but I'm running on a lowly mac mini G4 1.42, so it doesn't really bother me for the moment.

Simon

[tufty]

I should add, although compiling is a bit of a nightmare, it would be a lot more so if it were not for the wonderful work carried out by Hrvoje, and the comments made everyone here.

The biggest pain I had was compiling mico, still haven't found the magical combination for building 2.3.12. It would, of course, be easier if I was willing to use fink or darwinports, but I dislike both of those with a vengeance.

[hjasak]

All you need to do to get mico to compile is to configure it with similar options as the linux build and let it fail.

If you look at the failure location it actually breaks on an

#error Woops!

Just get rid of that (you need to edit the source of mico) and it will build fine.

For the rest of the java-related stuff, I would suggest using the changes I made in my last version (both linux and Mac), which updates it to java-1.5. With those, everything works.

Enjoy,

Hrv

[tufty]

7 hours of compiling and a disk image 50 times the size of the hard drive on my first Mac later...

Once I realised the patches set Java to 1.4.2, and I'm running 1.5, I managed to get FoamX to work. That's good, although I have no particular issue with text editing anyway.

Shutting down FoamX leaves loads of orphan processes. It's a bit of a pig, loads of kill-9 required. Still, it's working, and I can live with that.

ParaView is being tricky though. I guess I've fouled up the paraFoam stuff, I get the following error:

# Error or warning: There was a VTK Error in file: /Users/simon/Desktop/Paraview/ParaView-2.6.1/GUI/Client/vtkPVWindow.cxx (2572)
vtkPVWindow (0x5883400): Cannot read file information when no reader is specified. This probably means that the reader for the file with name: ./cavity.foam cannot be found
ErrorMessage end
ErrorMessage
# Error or warning: There was a VTK Error in file: /Users/simon/Desktop/Paraview/ParaView-2.6.1/GUI/Widgets/vtkKWApplication.cxx (1701)
vtkPVApplication (0x550b5c0):
Script:
paraFoam.pvs
Returned Error on line 11:
invalid command name ""
ErrorMessage end

any ideas as to what might be wrong?

[hjasak]

Yup, your reader library did not compile. Please keep in mind that you have to build your own paraview from scratch in order to compile the reader (not easy).

To check, go to applications/utilities/postProcessing/graphics/PVFoamReader and do

./Allwmake

Look at the messages, missing headers etc - it should build both vtkFoam and PVFoamReader. Do you have cmake?

You're close now, keep at it.

Hrv

[gschaider]

Hi Simon!

Just some quick comments.

@FoamX: this seems to have to do with the relatively strange implementation of ps (and related utilities): the output they produce is clipped to (I think) the width of the terminal. This sometimes removes the actual command name and therefor the processes can't be found by the scripts.

@size of disk image: if you want to use an even bigger disk image ;) you can compile it in debug mode. The only thing that is different from the standard Linux-settings is that the fromat of the debug symbols should be specified as -gstab3 because the standard g++-format (DWARF) is not supported by Darwin-dylibs.

[tufty]

Ah, Hrv, that would be it. I had to futz with the cmake stuff last time, too, forgot that. I don't overly like cmake, it has to be said

Bernhard - ps on OSX is a BSD implementation, not a SysV one, although it takes some of the SysV/Linux options too. I'll have a shufty at the script and work out what needs to be fixed, it's usually a question of adding a 'ww' to the commandline, but if it's being used like linux that the options and subsequent sed stuff need to be changed entirely. Easy enough to fix, though.

Right, as I thought. For OSX (and probably the *BSDs), the ps options in killFoamX and runFoamXHB really want to be -uxww, and the order the fields come back is different, so the final awk wants to print $2, not $1. I'd actually consider seeing if the system has 'killall' and only use 'myKillAll' as a fallback, TBH. I'm a bit tied up today, might see if I can't rewrite them to be a bit more sensible / tolerant tomorrow or maybe tonight if I'm bored.

Simon

[tufty]

Finally, 1.4 builds and runs, with FoamX and Paraview 2.6.1. Yes, I know 2.6.2 is now out. No, I don't want to chase that point release

Thanks, guys & gals.

Simon

[bouke]

Sorry for the slight delay, I was out of the country for a few days.

@Bernard ("foamInstallationTest is only an indication: Why is it failing?")

I looked into it and found that one of the reasons that foamInstallationTest fails because it expects a dfferent path and slightly different format for the ping command. Not critical but probably should be included in a patch sometimes, as not so knowledgeable users (like me) are quite likely to try foamInstallationTest?

I made this in the "pingTest())"
...
case $OS in
SunOS)
.....
;;
Darwin)
PINGTEST=`/sbin/ping -c 1 $1 2>&1`
if [ "`echo $PINGTEST | grep "1 packets received"`" != "" ] ; then
(etcetera)

Now I get a positive reply from it.

@Simon: you are right, readline is already installed.

Anyway, thanks for the help. I'll see if I can get it a bit further once I have gotten rid of my jetlag. I also need to get the parallel stuff and FoamX to run...

By the way, for Intel Macs there are some virtual machines that may be an easy solution to run OpenFOAM. They are not free but quite cheap (I got mine, Parallels Desktop, for 79 Euros but I think there are more options lately) and you can install any flavour of Linux on them. OpenFoam installed on my SuSE Linux VM in 20 minutes or so (from binaries) all up and running. I suppose I will take a slight performance hit (and probably loose one of my cores), but it sure is a quick way to get started.

[tufty]

Oh, another thing.

You might want to put your personal "run" directory on a case-sensitive file system, too. Xoodles, for examples, expects boundary conditions for "b" and "B", which is a bit of a pain on HFS+

Simon

[martin]

Hi,

Has anyone successfully compiled decompositionMethods on an intel mac? I am using the macport version of LAM-7.1.1 and got the following error:

wmake libso parMetisDecomp/ParMetis-3.1/ParMETISLib
ld: multiple definitions of symbol _create_scalable_zone
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libpthread.dylib(scalable_malloc.
So) definition of _create_scalable_zone
/opt/local/lib/libmpi.a(scalable_malloc.o) definition of _create_scalable_zone i
n section (__TEXT,__text)
ld: multiple definitions of symbol _malloc_freezedry
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libpthread.dylib(scalable_malloc.
So) definition of _malloc_freezedry
/opt/local/lib/libmpi.a(scalable_malloc.o) definition of _malloc_freezedry in se
ction (__TEXT,__text)
ld: multiple definitions of symbol _malloc_jumpstart
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libpthread.dylib(scalable_malloc.
So) definition of _malloc_jumpstart
/opt/local/lib/libmpi.a(scalable_malloc.o) definition of _malloc_jumpstart in se
ction (__TEXT,__text)
ld: multiple definitions of symbol _scalable_zone_info
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libpthread.dylib(scalable_malloc.
So) definition of _scalable_zone_info
/opt/local/lib/libmpi.a(scalable_malloc.o) definition of _scalable_zone_info in
section (__TEXT,__text)
ld: multiple definitions of symbol _scalable_zone_statistics
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libpthread.dylib(scalable_malloc.
So) definition of _scalable_zone_statistics
/opt/local/lib/libmpi.a(scalable_malloc.o) definition of _scalable_zone_statisti
cs in section (__TEXT,__text)
ld: multiple definitions of symbol _szone_check_counter
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libpthread.dylib(scalable_malloc.
So) definition of _szone_check_counter
/opt/local/lib/libmpi.a(scalable_malloc.o) definition of _szone_check_counter in
section (__DATA,__data)
ld: multiple definitions of symbol _szone_check_modulo
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libpthread.dylib(scalable_malloc.
So) definition of _szone_check_modulo
/opt/local/lib/libmpi.a(scalable_malloc.o) definition of _szone_check_modulo in
section (__DATA,__data)
ld: multiple definitions of symbol _szone_check_start
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libpthread.dylib(scalable_malloc.
So) definition of _szone_check_start
/opt/local/lib/libmpi.a(scalable_malloc.o) definition of _szone_check_start in s
ection (__DATA,__data)
/usr/bin/libtool: internal link edit command failed
make: *** [/Users/karmar/OpenFOAM/OpenFOAM-1.4/lib/darwinDPOpt/libparmetis.dylib
] Error 1


Any idea?

Thanks in advance,
Martin

[egp]

I successfully compiled 1.4 with openmpi on my new dual-quad-core MacPro. After using Bernhards latest patches, I had to do the following,

1. create mplibOPENMPI in wmake/rules/darwin
2. set WM_MPLIB=OPENMPI in .OpenFOAM/bashrc
3. edit stdheaders.h in the ParMETISLib to point to the sys/malloc.h.

I ran the rasInterFoam damBreak tutorial with 4 processors and a grid that is 4x larger. Everything looks good, however, I've not yet done a scaling study. With 16GB RAM in this machine, I'm interested to test its capability in problem size and performance.

I also installed paraview3 from disk image, but have been struggling to compile from source. I'll probably back off from the bleeding edge back to 2.6 to see if that helps.

Right-click using the Apple mighty Mouse seems to be working fine.

Bernhard, if there is anything I can do to help with the Intel-Mac porting, let me know.

Eric

[rmorgans]

I'd be interested in your scaling results. I've been working on one node of our new supercomputer:

(SGI Altix XE310 compute nodes, with dual Intel "Clovertown" quad-core 2.66GHz processors and 16GB memory per node)

We found very poor scaling, still trying to work out whats happening. According to our computing guys it may be "if the OS migrates processes between cores, and then you lose all your cached data" - or it could be memory bandwidth problems. I'll keep you informed if we find a fix.

If you want to test on a larger dambreak problem, I've made a 3d one (82^3 cells) and some scripts for timing runs on 1,2,4 & 8 processors.

Drop me an email rick dot morgans at gmail dot com if you want this.

Rick