[gschaider]

The problem is that the preprocessor symbol LITTLE_ENDIAN is set by the header /usr/include/ppc/endian.h to a value (BIG_ENDIAN is set as well). Because of this the conditional defaults to LITTLEENDIAN.

My ad-hoc fix is to insert

#ifdef __DARWIN_BYTE_ORDER
#if __DARWIN_BYTE_ORDER==__DARWIN_BIG_ENDIAN
#undef LITTLE_ENDIAN
#else
#undef BIG_ENDIAN
#endif
#endif

before the tests that set LITTLE_ENDIAN.

(This test should work correctly on the forthcoming Macs with Intel-processors but for obvious reasons I couldn't test this)

[hjasak]

Pop! Fizzz

I've got paraFoam running on my Mac and everything is fine. The only app that currently causing trouble is engineFoam, which links both the thermophyiscalProperties and triSurface libraries (both with their copy fo the flexer). Bernhard, I would be very interested to know if this one links and works for you.

FoamX. The problem is that mico-2.3.11 is not available and tring to port it is too much work. The last release was on 13/Oct/2003 and I'm not sure if the project is still alive. I personally don't use/need FoamX (apart from for presentation purposes) so I'm not too bothered. Suggestions, anyone?

That's about it - I'll put in some more effort after the next OpenFOAM release to deal with flex. There is still a question of renaming the files. I am not at all keen on renaming the whole lot to suit Micros**t and Mac should have a grown-up filing system available. As I see it, we've got 2 options:
- use a script which automatically changes the fine names (.cpp, without the upper-lower case clashes) and do this after each release. We can then massage each new release into this shape and make a binary Mac distribution.
- use Bernhard's trick adn create a little partition for the FOAM source to live in.

If anyone is interested in the Mac port, please give me a shout.

Hrv

[traumflug]

> - use a script which automatically changes the fine names ...

This is probably asking for trouble. Either rename all files for all platforms or ...

> - use Bernhard's trick and create a little partition for the FOAM source to live in.

The case sensitivity issue isn't unique to FOAM, Apple engineers suffer them as well: <http://www.opendarwin.org/projects/d...ndex.html#init>

> If anyone is interested in the Mac port, please give me a shout.

*shout*


Markus

[gschaider]

Hello Hrv!

@engineFoam: I ran the kivaTest Tutorial without problems (so: yes, engineFoam linked without problem)
I don't feel guilty of doing anything especially clever while compiling so I'm listing some other points where my installation might differ from yours (apart from the linker options):
- I'm using only XCode 2.0 (with gcc 4.0.0) which is not the newest version (this is another story: fink)
- I'm using the released 1.2 sources (I guess you're having the cutting edge)

@FoamX: I think having a GUI eases the introduction to OF, but in my experience people tend to go back to the text-editor (don't get me wrong I really like the possibilty to adapt it to new solvers, but ... lets discuss this elsewhere)

Mac port & shouting: I think my interest is obvious. Shout. Shout.

If there ever is a Mac-Binary-Distribution my proposal would be to pack it in a sparse DiskImage with the correct file-system instead of a tar. Installation would then consist of 'ln -s /Volumes/FOAM ~/OpenFOAM'
(maybe there is a similar DiskImage-program for the Windows-World; but that's just a dream I have)

One afterthought on the BIGENDIAN problem: shouldn't this go into a central place (for instance the OSspecific-hierarchy), preferably with a preprocessor symbol that is less likely to clash with other headers (FOAM_LITTLENDIAN). I think all utilities that write binary data could profit from that.

[hjasak]

Hi All Mac Lovers,

I will start a clean build over night and then I need a word on how to create a "sparse DiskImage with the correct file-system" (an E-mail from the person in the know would be appreciated). We can then have a little experiment trying to deply this, ideall both Tiger and Panther and we'll take it from there.

I know the first attempt may be less than perfectly polished so please be patient :-)

Hrv

[traumflug]

This is why I posted the hint about OpenDarwin developers:

hdiutil create -size 4g -type UDIF -fs HFSX -volname Builds \
-uid 0 -gid 0 -attach Builds.dmg

No need to have a sparse image, though. Sparse images grow as they are filled, but they are slower as well.


Markus

[traumflug]

Second thought:

Hrvoje, you want the "sparse" disk image not for building, but for distibution, right?

What Bernhard probably meant is not a sparse, but a compressed disk image. To create such a thing:

1) Build all the stuff elsewhere.

2) Use disk utility to create an ordinary read/write disk image. Making it a few megs too big doesn't hurt at all (see point 6). Mount (attach) this image.

3) If you rely on file ownership on the disk image, select the mounted volume's icon, open the info panel for it and uncheck "ignore file ownership on this volume". This is at the very bottom of this panel, possibly hidden by default.

You should be able to create files with different users on the image's volume, then.

4) Copy all the stuff needed onto this disk image. Adjust the volume's name, get rid of unneccesary stuff (e.g. .DS_Store files, trash contents ...).

5) Unmount (detach) the disk image.

6) Use disk utility to convert the read/write image to a compressed image. Unused blocks in the image's volume are compressed to zero size then. Used blocks are compressed using zip.

7) Test your work by double-clicking the image. It should appear as a read-only volume within seconds, the decompression is done as needed.


Markus

[hjasak]

Well, we're in business. I have recompiled the stuff and made a disk image as described + uploaded it on my web site.

Markus, thanks for your help and the detailed instructions. Could you please try and download the compressed disk image and run off it. I would recommend making a copy of the icoFoam/cavity tutorial and running blockMesh+icoFoam+paraFoam to see if it all works.

Please note that this is all still VERY experimental and there's a bunch of things I am very unhappy about (e.g. the size of the optimized main library is over 200 MB, twenty times more than it should be). I understand the Mac web site has got a pretty low download limit so please be gentle with it. Once we get it to work, I'll try and find a better location for the disk image or just burn some DVDs...

(2 hours later, the file is still uploading).

I've got to get on with other things right now, but please keep me posted with your notes, problems and similar.

Hrv

[gschaider]

Well. It's quite embarassing: I meant a sparse image, but used a regular image myself. (Preaching water and drinking wine)

The reason why I was going for sparse was to make the usage for novices as simple as possible:
1. mount image
2. do the symbolic link ('ln -s /Volumes/OpenFOAM ~/OpenFOAM' - assuming the Image was created with -volname OpenFOAM)
3. call the init-Script
4. find his directory ~/OpenFOAM/theuser-1.2 as described in the docu
5. Start working and the image adjusts itself to your needs

With a read-only image step 4. would not be possible (the user would have to convert the image back to uncompressed before using it as writeable)

What I would propose would be: follow Markus' instruction steps 1-5 with a 1Gig-image

Compress the image in the old-fashioned way with gzip (in theory this should make the image as small - if not smaller - as the actual data in the image)

If that image gets downloaded and unzipped (Safari does this automagically I think) the user finds on his harddisk an image that can be used as described above. If he needs more space than the 1Gig he can use 'hdiutil resize' to grow the unmounted image.

[gschaider]

Hello Hrv!

Didn't get your last message before I sent mine. Anyway: the mail-library you're refering to is libOpenFOAM.dylib? In my build it's 9.3 MB (which would fit your description of being a twentieth of your lib).
Maybe we should compare the compiler-switches.

[hjasak]

Yes, that would be great! If you've set it up in the standard way, the c++ compiler options should be in the file:

wmake/rules/darwin/c++

Could you please post it here (if you want to see mine, pls shout).

Thanks,

Hrv

[traumflug]

> Could you please try and download the compressed disk image and run off it.

I'd like to ... but the only file available right now is "OpenFOAM-release" (http://homepage.mac.com/h.jasak/.Pub...AM-release.dmg) right now and this is zero bytes in size ...

[traumflug]

> With a read-only image step 4. would not be possible

Is it necessary to have a read-write image to run the software? If yes, this should change, IMHO.

> Compress the image in the old-fashioned way with gzip (in theory this
> should make the image as small - if not smaller - as the actual data in the image)

Make sure to always put a finished build onto a fresh image, then. If you modify or delete files on an existing image, (i.e. buld the libraries on the image) the unused data won't be zero'ed out and the (externally) compressed image will grow.

I don't know how to shrink a sparse image (get rid of the unused space) for distribution.


Markus

[gschaider]

If I remember it correctly I used the normal linux-rules as a template and beat them until they cooperated (but changed as little as possible):

c++ says:
.SUFFIXES: .C .cxx .cc .cpp

c++WARN = -Wall -W -Wno-unused-parameter -Wold-style-cast

CC = g++ -m32

include $(RULES)/c++$(WM_COMPILE_OPTION)

ptFLAGS = -DNoRepository -ftemplate-depth-30

c++FLAGS = $(GFLAGS) $(c++WARN) $(c++OPT) $(c++DBUG) $(ptFLAGS) $(LIB_HEADER_DIRS) -fPIC

Ctoo = $(WM_CC_DRIVER) $(CC) $(c++FLAGS) -c $$SOURCE -o $@
cxxtoo = $(Ctoo)
cctoo = $(Ctoo)
cpptoo = $(Ctoo)

LINK_LIBS = $(c++DBUG)

LINKLIBSO = $(CC) -dynamiclib -undefined dynamic_lookup $(c++FLAGS)
LINKEXE = $(CC) $(c++FLAGS) -L$(FOAM_LIBBIN)/dummy -lPstream



In addition c++Opt defines:
c++DBUG =
c++OPT = -O3 -ffast-math

Some things I noticed while looking at the rules:
- the -m32 flag survived from the i386-settings
- I think the last two options in LINKEXE are historic artefacts

[hjasak]

Yup, that is the file but it's huge and still uploading. Maybe we should wait for another try after Bernhard and I merge the compiler options...

Hrv

[traumflug]

> With a read-only image step 4. would not be possible

Is it necessary to have a read-write image to run the software? If yes, this should change, IMHO.

> Compress the image in the old-fashioned way with gzip (in theory this
> should make the image as small - if not smaller - as the actual data in the image)

Make sure to always put a finished build onto a fresh image, then. If you modify or delete files on an existing image, (i.e. buld the libraries on the image) the unused data won't be zero'ed out and the (externally) compressed image will grow.

I don't know how to shrink a sparse image (get rid of the unused space) for distribution.


Markus

[hjasak]

Looks like I've added lots of debug info into the library and forgot about it. Recompiling...

Thanks for the image info, I'll keep it in mind.

Hrv

[gschaider]

@markus' remarks:

1. necessity of a read/write image: in my simple mind I assumed that everyone sets up stuff the same way I do: the root directory of my image looks like this:

OpenFOAM-1.2
bgschaid-1.2
otheruser-1.2

The last two were created by the init-script.

That way all the user directories are in a caseSensitive filesystem (TBH: I never tried writting OF-data to the regular FS. I see no reason why this shouldn't work, but the devil never sleeps: data files who's names only differ by case)

With that set-up obviously the image has to be rw.

The other way would be to have an image that is identical with the directory OpenFOAM-1.2. In theory this wouldn't have to be rw provided:
- you don't want to apply patches and recompile
- you don't want to change site-wide settings (.OpenFOAM-1.2/controlDict for instance)

of course the second way has it's benefits for the parallel installation of versions.

2. I experimented with my working-image (where I did all the compilation and some simulation data is in it): It's a 1Gig Image, df reports 790MB, after zipping it it was 200MB of size. It's bigger than the equivalen Linux-Downloads (125MB - that is General and LinuxOpt, no java, no paraview)

[hjasak]

OK, there are now 2 images on my web site:

OpenFOAM-1.2.dmg, 86.7 MB
- this is the OpenFOAM-1.2 build disk image, unpacking into OpenFOAM-1.2

OpenFOAM-1.2-darwinBin.dmg, 134.8 MB
- this is the contents of the binary tools directory

Have a go and let me know if you succeed,

Hrv

[gschaider]

Hi!

I tried the Images over the weekend. They work fine but I've got some remarks I want to make (I tried to keep the images readOnly)

- WM_PROJECT_INST_DIR is hardcoded in the bashrc-files. That makes a symbolic link to the right location necessary (or make the images writable)

- This one is a general problem with the startup-script for paraView: it is modest enough to append itself to the PATH and LD_LIBRARY_PATH. Because of this the OpenFOAM-paraview is always 'shadowed' by a previous non-OpenFOAM-installation which leads to a failure in paraFoam (I've seen this on Linux-machines too). I would propose to change this behaviour to prepending to the path.

- paraview seems awfully large and slow at startup (compared to the 'official' binary. Could there be some debug-information too?