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?