Hi all! I started compiling
 

Hi all!

I started compiling OpenFOAM 1.4 on my iBook. So far everything except paraFoam, FoamX and the patchTools (pre- and postprocessing is not important ;) ) works.

For those who want to give it a try (and not wait for the disk-images) I have a very sketchy HowTo posted written on http://openfoamwiki.net/index.php/Ho...e_OpenFOAM_Mac
(additional technical details can be found in the thread "OpenFOAM-1.3 for Mac OSX Darwin (10.4)" on this Board)

There is a patch there with all the changes I had to do to get it to compile with the standard compiler you get from Apple.

I'll update the page as I find time/I get the other stuff to compile. Any contributions/comments welcome

Bernhard

Hi Thanks for all the work!
 

Hi

Thanks for all the work!

A few comments:

- 'Disk Utility' can create disk images with case sensitive file systems (I added a remark to the wiki page)

- The patch seems to be missing the rules for the 'darwin' architecture.

- The patch fails with the file readSTLASCII.L (your fix seems to already be in the upstream sources)

- flex++ was already installed on my system (probably by XCode)


Michael

Hi Bernhard, I have updated
 

Hi Bernhard,

I have updated the FoamX and patchTool stuff in my latest 1.3 port. Comparing it against 1.4, you can simply copy and paste (no changes elsewhere).

Compilation of mico is a pain, but all that is really required is to change the options (./configure will bitch at you) and removed the "Woops" error when the compilation fails. The other game is all about having or not having -lssl in orbOptions (and maybe another library, I cannot remember).

AS for paraview, that one is more of a struggle. Do a cmake, go for a debug option, select to look at detailed options and remove all -g + change -O0 to -O2 or similar. It will then build, but expect trouble.

Keep me posted, I don't want to be the only one having to go through McPain every few months http://www.cfd-online.com/OpenFOAM_D...part/happy.gif

Hrv

I've just tried following the
 

I've just tried following the steps on the Wiki page, and basically echo Michael Wild's comments: Disk Utility can be used to create the disk image, and I already have flex++.

I need to get the wmake/darwin rules directory from somewhere; patch is not suitable for distributing new files without some esoteric options I believe. If someone could point me to a suitable set of rules, I think I'd be good to go.

Hi! @everyone: I will updat
 

Hi!

@everyone: I will update the Wiki-Page accordingly (just not today: I had a long weekend and therefore am exhausted)

@hrv: I bypassed all the mico problems by using the version from Darwin-Ports. A simple "sudo port install mico" took care of all the stuff for me. I then configured the usual DarwinPorts-Path (/opt/local) as the Mico-Base-Path and FoamX compiled without a problem (just on "I don't want ulong give me unsigned long"-complaint from the compiler). I've seen that Darwin-Ports also has LAM, OpenMPI and MPIch(2) so I would recommend using these as well (but I havn't bothered to try yet. There's no use with a single-core notebook.)

@hrv part2: Concerning the right-click problem in FoamX you described in the other thread: that happens when you right-click the Mac-way (Ctrl+Mouse)? I can reproduce that with the track-pad BUT when I use an external USB-mouse the right mouse-button works. So my guess is that the JVM swallows the Ctrl-Keycode for its own purposes, but then doesn't do anything useful with it.

@jturner: You're right. The wmake/rules/darwin files are missing from the patch (the reasons for that are .... complicated). I'll upload a tar of that directory to the Wiki (but there is nothing mysterious there)

Forgot to mention: paraview is
 

Forgot to mention: paraview is done since saturday. I already posted the stuff I remembered to the Wiki

Hi, I just wonder if the howt
 

Hi,
I just wonder if the howto for compiling OpendFOAM 1.4 for Mac can be used for compiling on a core duo imac. It seems that the compilation was made on a powerpc based mac and I don't know if there are substancial differences on intel based macs. Anyway, I'll give it a try this evening.
By the way, I don't understand why I need a disk image with case sensitive file system.
Regards

Now that I have the rules/draw
 

Now that I have the rules/drawin directory, the build is working fine for me on my MacPro. Note that I haven't installed anything from DarwinPorts, I'm not clear (it would be great if someone could clairfy) if there is a problem with using the FOAM versions of MPI / Mico / LAM, or whether it simply speeds up complication to use the DarwinPorts versions.

I am having some issues with the 'wmkdep' tool, I've fixed one problem already, but am getting continual crashes. Been a while since I messed with lex, but I will post a patch one I discover what's going on. I suspect I'm only aware of the crashes because I have CrashReporter in Developer mode - I can't see any reason why it should fine for other Macs but crash for me, so I suspect it is silently failing normally.

Also, I don't like the disk image thing, but assumed it was necesary because there are files in the tree whose name differs only by case.

The version of lex that comes
 

The version of lex that comes with the Mac is ancient - I have seen similar failures on old SGI machines. Options are:
- upgrade lex on your Mac (not sure about it)
- let it silently fail. It fails in the assembly of dependencies, which is not too bad unless you are doing active library development on the Mac.

Hrv

Hi Xavier! @compiling on co
 

Hi Xavier!

@compiling on core duo: The answer would be: In principle yes, but I havn't got an Intel-Mac to test it. But if you are willing to try I am willing to help you

@case-sensitve file system: Try on the command line of your Mac:
touch scalar.C
touch Scalar.C
when you look at contents of the directory you will only find one of those files because the Mac-Filesystem knows about Capital-Letters but it doesn't allow filenames to only differ by lowercase/uppercase (the same goes for the Windows-Filesystems FATxx and NTFS). In the OF-sources there are instances of such "name-clashes" (I think the matter is discussed in more detail somehwhere else on the Board)

Bernhard

@james: the wmkdep problem cou
 

@james: the wmkdep problem could have to do with a ulimit on the number of open filehandles (at least that was a problem I used to have). It's to low for the number of headers scanned. Check with ulimit -a and set it with ulimit -n xxx (I have 2048, don't know what the original value is)

Bernard - this is the first pr
 

Bernard - this is the first problem, the one I've fixed, by inserting a call to fclose() in the customized yywrap() implement - that fix seems to work fine. The second problem is with yy_get_next_buffer segfaulting - as HJV said I can ignore it, but it's annoying me. A lot.

Our version of flex is 2.5.4, which it's true is old (current is 2.5.33) but I'm surprised if that would explain the crashes. Fink only includes 2.5.4a - DarwinPorts includes 2.5.33 which I guess I shall try now, just to see what happens.

@james: I checked. My machine
 

@james: I checked. My machine has the 2.5.4-version too. So the version per se can't be the problem with your segfaults. (The problem can't be from your fclose-fix, because it closed one file too many - would be a classic reason for a segfault)

@everybody: I've added a second patch to the Wiki page. This
- points the installation to the darwinPorts-Mico
- makes it possible to compile PVReader without human intervention
- removes some warnings with shell scripts by replacing 'head -1' with 'head -n 1'

Last things missing for the full Foam-experience are (IMHO)
- a MPI-implementation
- a fix to the right-click-problem in FoamX (can anyone with a different configuration than Hrv and me (which are Notebooks with a PowerPC) report whether whether he (or she) has that problem too - that would help find out where the problem comes from)

Some progress on wmkdep, I had
 

Some progress on wmkdep, I had great success updating the code to use yy_push/pop_buffer instead of a manual stack of buffers. As a result, I only got one crash during a complete build of OpenFOAM/applications. Of course it's bad that there were any crashes, and doesn't explain what's going on - there is nothing 'wrong' with the manual stack the original wmkdep maintains.

The fclose fix is unrelated to the crashes - it simply fixed all the 'file not found' warnings I saw, due to the open file handle limit being excedded, and hence fopen failing.

In terms of applying the new patch, is reverting the old patch and applying the new one safe, or would you suggest starting with a clean OpenFOAM tree?

Hi James! You're talking ab
 

Hi James!

You're talking about the second patch on the Wiki? I think I was a bit unclear in my description. This patch should be applied _in addition_ to the first patch. (I guess the v1, v2-tags are a bit misleading) So definitly no clean tree.

regards
Bernhard

I've just added an enhanced er
 

I've just added an enhanced error.C to the Wiki-page. This implements the backtrace that prints the stack in case of program errors for Darwin (previously this was only possible under Linux)

The only problem is that I only have a OF compiled with Release-options on my notbook (Please don't laugh: the harddisk is too full to accomodate an additional debug-Version). So if I insert the line

FatalErrorIn("crashFoam") << "Program dies for no good reason" << abort(FatalError) ;

in a program I get a correct call-stack but no sourcefiles and linenumbers. This (files and numbers) should work with a Debug-version. So if anyone here has a debug-version on his Mac and could test it, I'd be grateful (same goes for our friends with Intel-Macs: I only have a PowerPC)

I'm be interested in compiling
 

I'm be interested in compiling version 1.4 on my Mac Intel as well. If any developments were made in this regard, please post them and I'll give them a try.

Thanks

Doug

Hi Doug! To my knowledge th
 

Hi Doug!

To my knowledge the best chance to get it to work on an Intel-Mac is to follow the instructions posted on the Wiki-Page above (I see no reason why it shouldn't work, but I wish I had a Euro for every time I said that).

I have no feedback from Intel-owners. This could mean
a) there are no problems
b) nobody has tried yet
c) people don't like to talk about their problems

If you run into problems/unclarities in the instructions, ask here or contact me directly

Bernhard

If it makes you guys feel bett
 

If it makes you guys feel better, my PowerMac laptop was stolen 2 weeks ago. This means I am (hopefully) getting a new Intel Mac and the code will be re-ported and distributed as per usual. Boernard, please hold on to your PowerMac http://www.cfd-online.com/OpenFOAM_D...part/happy.gif and between us we could cover it.

Hrv

Hrv- I'm sorry to hear that
 

Hrv-

I'm sorry to hear that your Mac got stolen. However, I am thrilled that someone wants to assume the task of getting it working on an Intel Mac. I've been working on it for about a week now with the kind help of Bernhard, but my limited linux experience has hindered my progress. I'd be happy to help in any way I can.

-Doug

Hi Guys, I am trying to get
 

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

Hi! One of the problems wit
 

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

Hi, I suppose the rules are
 

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)

"the additional tar archive Da
 

"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)

Ok, applying the patches etcet
 

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

First hitch: I got a "conflict
 

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

Hi Bouke! To be honest: I n
 

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

Hi Bouke. Just been through
 

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

I should add, although compili
 

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.

All you need to do to get mico
 

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

7 hours of compiling and a dis
 

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?

Yup, your reader library did n
 

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

Hi Simon! Just some quick c
 

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.

Ah, Hrv, that would be it. I
 

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 http://www.cfd-online.com/OpenFOAM_D...part/happy.gif

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

Finally, 1.4 builds and runs,
 

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 http://www.cfd-online.com/OpenFOAM_D...part/happy.gif

Thanks, guys & gals.

Simon

Sorry for the slight delay, I
 

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.

Oh, another thing. You migh
 

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

Hi, Has anyone successfully
 

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

I successfully compiled 1.4 wi
 

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

I'd be interested in your scal
 

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