I'm trying to build OpenFOAM
 

I'm trying to build OpenFOAM on MacOSX. It is really hard to understand the building process and the documentation is really poor. Has someone succeded in compiling foam on MacOSX?

Thanks,

Mauro.

We have been asked several ti
 

We have been asked several times to do a port to OSX but are unable to do so because we don't have a machine here to do it and maintain it on. We asked Apple if they would lend us a machine or give us access to a porting centre machine but they didn't even reply. I have told those people interested in an OSX port that if they club together and provide OpenCFD with a machine we will do the port and maintain it but we have not had a reply from them either.

Yes the build process is complicated, that's because FOAM is complicated containing a great many libraries both native and imported and an even larger number of applications. I think there is some interest from users for a simpler build system which I would be happy to include in the OpenFOAM release when it is supplied to us. In the meantime users will have to persevere with the wmwake-based system we supply or create there own. We will endevour to provide better documention for porting in the future but we are being asked to do a great many things free of charge and this is not top of the priority list so I am not sure when it will happen.

Hi Henry; I'm not sure, but
 

Hi Henry;

I'm not sure, but I think sourceforge offers an Apple and Linux cluster for their projects.
A better option, IMHO would be to get OpenDarwin for i386 on an ISO image:
http://www.opendarwin.org/
(There's also a GNU-Darwin distribution somewhere).

cheers,

Pedro.

We are not part of sourceforg
 

We are not part of sourceforge yet and really I need local access to do all the pre/post processing stuff because doing that remotely is a right pain.

I am very happy with SuSE Linux on my machines and not directly interested in OSX at all so I don't want to go to all the trouble of installing OpenDarwin and even if I did I guess the binaries would not work on a real Mac OSX machine.

The bottom line is if the Mac community club together to get OpenCFD a machine we will do the port and maintain it, if not we won't.

Hi All, I intend to do a M
 

Hi All,

I intend to do a Mac OS X port in the next month or two, so if you're not in a hurry I suggest you wait a bit. However, I don't intend to ship a binary release i.e. everyone will need to compile their own version.

Hrv

Good!! we will wait impatient
 

Good!! we will wait impatiently for this. No problems in compiling it ourself; this is a quasi-rule in opensource developments.
Please, if possible, give us (if you prefer by private mail) a periodical status of your "porting"; just to know that it is going as you want.
In any case, if you need some help, let us know (at least let me know).

Do you intent to do the porting basing it on X11 or you will try the hard way to port it to cocoa?

Many many thanks.

Mauro.

Hi I'm still fairly new to
 

Hi

I'm still fairly new to c++ and compiling, but learning. I too would like a version of OpenFoam on MacOSX and would be happy to help with the porting. I'll need plenty of guidance, I'm afraid, but if there's any 'Donkey Work' that needs more effort than ability then I'd be delighted to help.

In the meantime, I also have Yellow Dog Linux on my mac and will try to compile on that, at least this will give me the code on Apple hardware.

Paul Wells

Any news on the porting to OS
 

Any news on the porting to OSX?

Thanks,

Mauro.

Yup, but not good. Got the
 

Yup, but not good.

Got the machine, got the compiler, I've set up the foam environment and compiled up a few basic things... and then hit a snag. HFS+, which is the filing system you get on your Mac is completely case-insensitive. This means that files like Dictionary.H and dictionary.H cannot be distinguished and that's a problem.

The number of such clashes in the whole of foam will be of the order of 50 or so and I would need to change them by hand (well, scriptable) and rename the files - I don't fancy doing that.

The second problem I've hit is that OS X seems to have a different system for handling shared libraries. As a consequence, g++ does not support the -shared option (producing .so files) and has some setup for producing .dylib files instead. Therefore, once the first problem is solved, there will potentially be trouble with this lot as well.

In short, reorganising the files will cause a divergence between two versions of foam and, together with the second lot, this is not worth my effort in the short term...

I am working on a Mac OS X ve
 

I am working on a Mac OS X version of FOAM as well, and also have not had very much luck. Actually, I have not been able to succuessfully build anything...I keep hitting snags. Does anyone know if all of the script files (Makefiles, shell scripts, etc.) can be run on the Mac right away? Or do I need to tweak those first? I appreciate any help.

I just got into the Openfoam f
 

I just got into the Openfoam forum a few weeks ago and just decided to start a port to Mac OS. Looks like there's still a lot of work to be done. I'm pretty savvy with Mac OS and building. Maybe I can help out.

As for the HFS+ problem, you can get around this by creating a UFS (Unix File System which is case sensitive). That's how I handle all my porting problems (Fortran is notorious for this, too). If anyone's interested in this I'd be happy to post the instructions.

I'd be interested, sure! I act
 

I'd be interested, sure! I actually just set up dual boot with Yellow Dog Linux and was about to try to compile from source. Don't see why this shouldn't work. I'll post when I have results.

Just a few pointers: - in t
 

Just a few pointers:

- in the XXX/.OpenFOAM-1.1/bashrc add a check for your machine type and set WM_ARCH and WM_MPLIB. You can leave WM_MPLIB empty (which will link in the dummy/ Pstream (which saves you having to compile lam or mpich))

- in the XXX/.bashrc add your architecture and set all the relevant variables to access gcc and java and such

- make a copy of e.g. $WM_DIR/rules/linux to $WM_DIR/rules/$WM_ARCH and adapt the settings in these files.

- have a look at XXX/Allwmake script which compiles up some binaries needed by 'wmake' itself ('cd wmake ; ./makeWmake')

- have a look at XXX/src/Allwmake and compile in the same order (leaving out the lam and mico if you don't want to run parallel or FoamX)

good luck,

Mattijs

I've spent the day trying to c
 

I've spent the day trying to compile on my Powerbook running Ubuntu linux. Gcc 3.4.3 compiled fine, I also compiled the wmake binaries, that are included with the sources precompiled for the popular architectures. I tried various hacks in the makefiles, gcc flags, using flex instead of lex. Some of the shared libraries compile but it fails when trying to build object files.

Two questions:
1 Has anyone already successfully compiled under linuxPPC?
2 Can anyone tell me a organised procedure of what files I need to change or create and which ones I can leave alone to save me working through everything?

Many thanks in advance

PS I got Paraview2.0.2 to compile and can send details if it is any use to anyone.

Paul

I have compiled FOAM under lin
 

I have compiled FOAM under linuxPPC many years ago and we would consider porting to and supporting this platform again once we find sponsorship to do so.

I have had a go at compiling o
 

I have had a go at compiling on native OS X; however, there are problems with the default filing system and given up on it. Recently OS 10.4 came out and there are rumours of supporting the "proper" (case-sensitive) filing system. Also, I am told that OS X will mount external efs disks and that's the direction I am leaning towards (not ideal because I want the stuff to run on my laptop without the external disk).

As for the porting, I am interested in the native Mac OS X (for me, that's the point of having a Mac) and not in Mac flavours of linux.

Hrv

Paul, I compiled on linuxPP
 

Paul,

I compiled on linuxPPC (Gentoo) a few months ago and I had to hack around some of the build scripts to get things to go in the right places (or what I consider to be the "right places" ;-))

Matt

Why not post what you did to h
 

Why not post what you did to help others who want to run on LinuxPPC?

Here's some help on "right pla
 

Here's some help on "right places" to configure a new port. I am a tcsh person so all will be given in terms of .cshrc files; an equivalent bash setup also exists.

For starters, all configuration should be done through environment variables. Also, none of the existing build configurations should be tampered with :-)

The first place is in ~/.OpenFOAM-1.1/cshrc (a copy of thsi directory exists in the FOAM installation for the new users). Here, under the $machineTest you can set up the machine-specific setup that a user can configure. If your machine does not exist, add another "else if" into the command.

The second place is OpenFOAM-1.1/.cshrc. Here, the FOAM-distribution part of the installation is set up. Again, there are some machine-specific things, like JAVA and the parallel communications library.

Finally in wmake/rules, there is a bunch of directories for each architecture in which the compilaion and linkage flags are set, compiler is selected and similar.

For applications there is a bunch of sub-directories in .OpenFOAM-1.1/apps, where the setup for various external (post-processing) apps can be manipulated. By default, the ones in OpenFOAM-1.1/.OpenFOAM-1.1/apps are sourced, but that can be over-ridden in ~/.OpenFOAM-1.1/cshrc.

I think that's about it - if I've forgotten something, please feel free to add.

Enjoy,

Hrv

Thanks Hrv. What do we do a
 

Thanks Hrv.

What do we do about the Java SDK? I can't find 1.4 for ppclinux

What is it used for in Foam?

Paul

Java is used for FoamX and pat
 

Java is used for FoamX and patchTool, if you can live without the pre-processor then you don't need it but if you want these applications then you will need a usable Java 1.4.?, older versions will not work.

Chris, I copied the OpenFOA
 

Chris,

I copied the OpenFOAM/wmake/rules/linux directory to "linuxPPC" and edited:
c: changed cc = gcc -m32 to cc = gcc
c++: changed CC = g++ -m32 to CC = g++
c++Opt: added "-mcpu=750" to c++OPT
cOpt: added "-mcpu=750" to cOPT
general: removed the "-melf_i386" option from LD

I can't remember how much of the .OpenFOAM-1.0 directory I changed. I don't think very much except to use my pre-compiled MPICH rather than OpenFOAM's bundled LAM.

Oh, and I also had a pre-compiled version of mico, gcc and all the other stuff that OpenFOAM bundles.

Hope that helps. If not I can post the full diffs.

Matt

Coming back to the topic of th
 

Coming back to the topic of this discussion: the build of OpenFOAM on mac OSX. I tried a lot of way without success. The problem of the file system case-sensitive or not is easily solvable, at least to compile the code. What I do is to create a disk image, to format it as a HFS+ case-sensitive, to mount it and to compile openFOAM on this mounted image.

But, thanks to the suggestions of Mattijs Janssens I can compile something, but at a certain point compiling fails.
Had anyone more chance in compiling openFOAM on OSX?

Thanks,

Mauro.

Here's my update: I have up
 

Here's my update:

I have upgraded my Mac to OS 10.4 which should make it easier to deal with the filing system issue. I have also bought an external disk and formatted it to be cases sensitive - it si not recommended to re-format the installation disk and do it there because it is likely to show tons of bugs in various applications regarding the "proper" filing system.

I have started the porting and got decent progress. The issues come in two flavours: Unix-related and compiler-related. The unix-related stuff is totally straightforward and deadly boring (reading lits of man pages and looking for headers) and the gcc stuff is due to the tact that OS X comes with gcc version 4.

Now, I cannot be bothered to deal with all of the gcc-4 stuff in foam version 1.1 because Henry tells me he's already done most of it in 1.2. The release of new foam should (have) happened any time soon so I'll carry on with the port once the new version gets officially released.

There will still eb problems with people trying to compile up teir own extensions on a Mac but at least I'll be able to demonstrate what it looks like.

The saga continues...

Hrv

Any news with this new version
 

Any news with this new version? I have the same troubles to compile it.

Thanks,

Mauro.

Compiled and running over here
 

Compiled and running over here. I want to fix the linker error I mentioned in the previous message, have a play with paraview etc and we should be in business. I am currently building on the case-sensitive filing system, but there's a bunch of scripts which will change it into .hpp and .cpp files + resolve the name clashes.

The remaining issue is that mico does not compile on OS X, which will require further digging...

Hrv

This is a great news!!! When y
 

This is a great news!!! When you have fixed the remaining problems (or also before if you want), can you post the main hints to be able to compile OF on OSX?

Thank you so much,

Mauro.

Hello, I am in a rush. I need
 

Hello, I am in a rush. I need to perform a CFD calculation. I would like to do it using OpenFoam on OSX, but I cannot compile it. Hrvoje or others can, please, give me some details on how to compile OF on OSX (here or at my email address).

Thanks a lot for any information,

Mauro.

I've got it working on my Mac.
 

I've got it working on my Mac. However, there is a bug in paraview which makes it core dump on Tiger and I don't want to announce the port before some post-processing is available. The port has been done in collaboration with Julio Ng, working at Apple Inc. and I would like to thank him and the company for their effort.

Further news and ported code will follow once the paraview bug gets fixed (Bug #2193 - MacOS X Tiger with X11 and Tk: segment fault)


Hrv

Does the port compile under Pa
 

Does the port compile under Panther? Paraview works fine in Panther. I could try compiling if that's any help

Hello Hrvoje, being new to
 

Hello Hrvoje,

being new to OpenFOAM, but being an CAD and Mac OS X old-timer as well, I'd like to join your porting efforts.

The previous posts sound like you're near to completion. Experience shows, waiting for Apple to fix a bug can take years. Hence, we/I should find a workaround.

As I'm not keen on duplicating your work, could you make some patch against the 1.2 release available - public or privately?


Thanks,
Markus

Hi Markus, Currently, there
 

Hi Markus,

Currently, there are only 2 problems:

1) foamFlex.

This is a foam-customised version of flex++ and it is used in several places in the code, e.g. reading mesh files or material properties. The problem occurs when I use foamFlex in 2 libraries and try to link them to the same executable. The one that's causing me trouble is in:

./combustion/chemistryReaders/chemkinReader/chemkinLexer.L

The actual problem is that the lexer has got an inlined virtual destructor and when I do this across 2 libraries I get a multiply defined symbol and (because it is virtual and connected with the virtual function tables) the error is fatal.

Currently, I cannot be asked to fix this one. I believe the compiler is right and major re-organisation of foamFlex is required to get it right. If you know the correct compiler/linker option to get around this one, I'd be very grateful.

Currently, it's hacked and all the apps are OK, I am happy with the temporary solution so let's move on. :-)

2) Post-processing.

As you know, the main post-processor for OpenFOAM is paraview. I can download and use the pre-compiled paraview from their web site and all is well. However, paraFoam uses a reader library and is MUCH more convenient than anything else. In order to build it, I cannot use the pre-built version of paraview (doesn't have all the stuff I need to build the reader library. This brings us to the problem of building paraview on Mac OS X from scratch.

There were a few problems with the older version of paraview (2.2.1) and because I'm running Tiger, I have switched to the latest stable release (2.4.1). Now, this all builds fine but when I try to run it (on its own!) I get a segmentation fault.

There is a bug report on this, but I think this is a red herring. Basically, if Apple can build paraview so that it runs, I should be able to do the same. I am pretty certain this is some linker option that needs to be added but haven't got the time to deal with it (very annoying!).

If you want to get stuck into this, you could download the paraview sources and rebuild paraview from scratch so that it works from your build.

For the rest, I can give you my development source and you can start running OpenFOAM on your Mac - I am interested in some performance numbers as well...

Hrv

Hello Hrvoje, being new to
 

Hello Hrvoje,

being new to OpenFOAM, but being an CAD and Mac OS X old-timer as well, I'd like to join your porting efforts.

The previous posts sound like you're near to completion. Experience shows, waiting for Apple to fix a bug can take years. Hence, we/I should find a workaround.

As I'm not keen on duplicating your work, could you make some patch against the 1.2 release available - public or privately?


Thanks,
Markus

Markus, Duplicate post? Co
 

Markus,

Duplicate post? Could you try again please.

Thanks,

Hrv

First, sorry for the double po
 

First, sorry for the double post. The server didn't appear to respond, so I tried again ...

> Basically, if Apple can build paraview so that it runs,
> I should be able to do the same.

Not sure about this. Looking at the OpenDarwin 8.0.1 release - it was built inside Apple from what they made available as open source, but nobody outside Apple was able to do this again.

> Now, [paraview 2.4.1] builds fine but when I try to run it
> (on its own!) I get a segmentation fault.

Segfaults can be tackled with a debugger. Easier to find than some hidden bug giving wrong results. :-) I'll check this out.

> For the rest, I can give you my development source ...

That'd be great. Could you make a diff against a public available release, please? As a dial-up user (*sigh*) a 60 MB downloads takes about 3 hour, here.


Thanks,
Markus

Hi! Over XMas holidays i tr
 

Hi!

Over XMas holidays i tried to compile OpenFOAM on my iBook and succsseded to a degree.

Beeing a lazy guy I decided to avoid the upper/lowercase-issues: i created with the hdiutl-command an image with a case sensitive filesystem (HFS+J if I remember it correctly), mounted it and used it as an "OpenFOAM-partition".

Am I right, that if I get dieselFoam/aachenBomb-case to run the chemkinLexer should be working? With my compile it does (but I havn't looked at the results)
(I linked the libraries with -dynamiclib -undefined dynamic_lookup, the environment variable MACOSX_DEPLOYMENT_TARGET was set to "10.3")

I didn't bother to get FoamX to run.

Same for paraFoam. I used foamToVTK to convert the data and postprocessed it with the newest paraview binary downloaded from the official website.
In the beginning I experienced a segmentation fault when I tried to open the generated vtk-files. After using the -ascii switch of foamToVTK paraview could read the files. I don't know if this is the same segfault you have been experiencing. Could the problem with the binary files be a lowerEndian/higherEndian-problem for the PowerPC?

If I remember it correctly I only had to introduce a new architecture to the bashrc. I then copied the linux-directory in wmake/rules and removed/added some options.

So far I have only tested it only with the damBreak tutorial-case (the results look OK) so I don't dare to speak of a success (but for my purposes everything I need is working)

PS: sorry for this collection of half-informations but I did that stuff 2 weeks ago and didn't have the time to work on it since then and the details got lost in the mist of time

Can you have a try and figure
 

Can you have a try and figure out that littleendian business?

You only need to define/override in foamToVTK/writeFuns.C the LITTLEENDIAN flag.

Any people with experience on other power architectures (ibm?) or other big-endian machines (mips)

Almost identical: - I'm run
 

Almost identical:

- I'm running Tiger (10.4)
- I've used an external disk with a case-sensitive file system
- did not use MACOSX_DEPLOYMENT_TARGET, works anyway
- the lexer I've commented out was in triSurface. I cannot remember which exec refused to link
- the option I've used was -undefined supress; the rest is the same
- some changes to the makefile were required to make it build .dylib files instead of .so
- there was some changes with the system-dependent includes, now properly added on #ifdef-s
- all codes run but I cannot look at the results.

The paraview saga continues... :-(

BTW, Markus, I keep my McSource on my McSite (sorry for the pun): http://homepage.mac.com/h.jasak/

I understand what you mean about slow download. If you send me your mailing address, I'll burn a CD and put it in the post.

Hrv

I inserted an #undefine LIT
 

I inserted an

#undefine LITTLEENDIAN

as suggested by Mattijs and recompiled foamToVTK. Now paraview can read the binary files. So it definitly is an Endian-problem which has ended now (I don't know why the machine thought of itself as a little Indian in the first place).

I apologize for all the bad puns in this posting.

Hi Bernhard, can you find o
 

Hi Bernhard,

can you find out why LITTLENDIAN is defined and send fix to that logic in writeFuns.C?