[gschaider]

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

[mwild]

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

[hjasak]

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

Hrv

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.

[gschaider]

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)

[gschaider]

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

[xponticq]

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

[hjasak]

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

[gschaider]

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

[gschaider]

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

[gschaider]

@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 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?

[gschaider]

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

[gschaider]

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)

[doug]

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

[gschaider]

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

[hjasak]

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 and between us we could cover it.

Hrv

[doug]

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