[gschaider]

Hi Eric!

Thanks for the feedback. In the next days I'll try compile 1.4.1 on my notebook. I hope that I can then provide a unified patch (which incorporates the additions you suggested. I guess I missed those because I never tested the stuff in parallel)

@Rick: Have you tried setting the processor affinity with mpirun (https://www.sun.com/products-n-solutions/hardware/docs/html/819-7480-10/mca-para ms.html havn't tried it myself yet) to see if it really is the cache? (another possibility would be to set the affinity with the taskset-command afterwards, but that would make it hard to get accurate measurments) But I'm betting on the memory bandwidth

[gschaider]

Just before I run into the weekend: I uploaded a patch for 1.4.1 to the Wiki-page. All the nexessary changes are in that patch (I hope)

It compiles with an OpenMPI from DarwinPorts.

Havn't done too much testing on it. Give me a word if you have problems (or if it works for you)

[gschaider]

Hi Eric!

I guess you may have noticed this thread:
http://www.cfd-online.com/cgi-bin/Op...how.cgi?1/4323
(conclusion: cores sharing memory bandwith is bad) But I would have expected a decent speedup at least for the 2CPU-case. Have you had a chance to do parallel benchmarks with non-OpenFOAM software?

[egp]

Hi Bernhard,

I wrote a small C++ code to compute Pi (e.g., see Using MPI, 2nd ed, by Gropp et al.) over 1e9 intervals. Parallel performance is almost perfect,

1 proc = 10.6 secs
2 proc = 5.3
3 proc = 3.5
4 proc = 2.8
5 proc = 2.1
6 proc = 1.8
7 proc = 1.5
8 proc = 1.6

However, there is almost no data being passed for this test case, which means that the performance doesn't suffer. Also, I did the timing using MPI::Wtime, which gave very different results from the command line "time -p mpirun -np ...".

Eric

[gschaider]

Hi Eric!

Have you tried a "pure" MPI-Benchmark? I think I once used this one:
http://www.dhpc.adelaide.edu.au/projects/MPIBench/
(don't know for sure if it's that one) and I think from the results one can judge the memory-throughput

Bernhard

[gschaider]

It was pointed out to me, that the first 1.4.1-patch that I uploaded to the Wiki was incomplete (very incomplete in fact). I uploaded a new version.

Sorry to everyone who tried and failed

[podallaire]

Hi guys,

thanks a lot for the patch and all the instructions ! I was able to compile everything including Paraview 2-4 on my MacBook Pro and it works really well ! I have only one remaining question :

- Is it possible to use a pre-compiled binary of Paraview3 and link it in order to build paraFoam ?

Best regards,

PO Dallaire

[gschaider]

Hi PO!

Look for discussions elsewhere on this board concerning ParaView3. Short answer is no, because
a) Paraview3 is not yet supported by paraFoam
b) to compile the PVReader you need at least the Paraview-headers and the CMakeCache.txt that was used to build the binary and none of those is distributed with the binaries

If you want to use paraview3 your options are:
a) use foamToVTK
b) use the OpenFOAM-filter built into (but not always enabled) in Paraview3 (see discussions elsewhere)

Bernhard

[podallaire]

Thanks for the infos Bernhard !
Have a nice day
PO

[sek]

It appears that a new version of operating system (v10.5 Leopard) wll be released on Oct. 26. Can I surmise it'll become much easier to install OF on Mac?

[sek]

It appears that a new version of operating system (v10.5 Leopard) wll be released on Oct. 26. Can I surmise it'll become much easier to install OF on Mac?

[podallaire]

Hey, it is already easy because of all the work those guys did here :-) Everything work so far on my Macs.

No, it will be exactly the same.

Regards,

PO Dallaire

[paka]

Might be easier, because new Leopard is going to use new Sun Microsystems disc partition, which if I'm not mistaken is called ZFS. It might have happened that Apple switched in Leopard to case sensitive operating system, but I'm just guessing.

[podallaire]

Hi,

from what I saw in the previous developer builds, ZFS was not the default file system. Hopefully, that will change for the final version.

[paka]

If I'm right, last two builds were suppose to have ZFS, but I'm not sure.

[hjasak]

Well, I already ordered it. When the pack comes, I will re-port OpenFOAM-1.4.1-dev to Mac OS X Leopard and report. If people are interested I can do the mountable disc partition again - is anyone actually using this at the moment?

Hrv

[paka]

Aloha Hrvoje,

Yes, definitely the mountable package would be great. I know couple people working on it.

Thanks,
Krystian

[podallaire]

Hi guys,

I installed Leopard and made some quick checks for OpenFOAM :

1) Mac OS X does not use ZFS in the installation - still does use the mac os x extended journaled - I do not see ZFS in disk utility
2) I can use my OpenFOAM disk image from Tiger, no problem
3) I tried to recompile but I saw an error somewhere with uint function - I'll try again later this week when I'll have more time
4) I did not compile paraview 2-6; in fact, I compiled Paraview 3 from scratch since it is Mac os X native - no problem here
5) FYI, I found a problem with X11 when compiling and linking opengl library with other programs (see http://wiki.finkproject.org/index.php/Fink:Packaging:Preparing_for_10.5#OpenGL_B ug). Don't know if this useful for the OpenFOAM project - just an info ...

Best regards,

PODallaire

[podallaire]

Hi,

The error I saw when I tried to recompile is :

primitives/uint/uintIO.C: In function 'Foam::Istream& Foam::operator>>(Foam::Istream&, unsigned int&)':
primitives/uint/uintIO.C:69: error: 'uint' was not declared in this scope
make: *** [Make/darwinDPOpt/uintIO.o] Error 1

PO

[gschaider]

Hi!

Don't have Leopard, so I can only guess how to fix this (BTW: which version of g++ comes with Leopard/XCode3 ?):

Try to replace the offending line
i = uint(t.labelToken());
with
i = (unsigned int)(t.labelToken());
(you WILL get a warning about an old-style cast)

Bernhard