[hjasak]

Dear All,

A joint development effort between Alstom Power and Wikki has resulted in a unified source tree for the upcoming foam-extend-3.2 release. The idea is to produce a unified development line that compiles on all platforms without changes, renaming, hacking, patches or short-cuts.

This has been achieved by introducing porting changes in the code, creating a native interface for the Windows OS in OSspecific/MSWindows and creating a proper build environment for all platforms.

The next release is now under testing, and under command of the Release Manager (Francois, thank you!). We are keen to have the source build across all platforms and receive reports on success or failure.

With the release, we will provide the usual rpm linux packages, and Mac OS X and Windows source and binary releases.

On Windows, we use MinGW, gcc-4.8.2 compiler and wmake build system, consistent with all other platforms. Source code support is complete and the release works fine in parallel.

Some basic info/instructions:
* Linux builds natively, as before. Source etc/bashrc and execute Allwmake.firstinstall
* Mac OS X: please switch to scotch600 in etc/bashrc. Source etc/bashrc and execute Allwmake.firstinstall
* Windows: prepare build environment by following README.txt in doc/buildInstructions/Windows. Once this is in place, source etc/bashrc.mingw and execute Allwmake.mingw

We have also tested binary release of the Windows compilation (libs and exe only), which works fine.

If you wish to try building the source RIGHT NOW, please check out the source:

git clone --branch nextRelease git://git.code.sf.net/p/openfoam-extend/foam-extend-3.1

and report on your experience. If you have suggestions for changes or how to facilitate the build, please drop me a line.

Hrvoje Jasak, Wikki

[ngj]

Good morning Hrvoje,

Thank you very much for this set of good news. I have not been close to a Windows computer yet, but I will hopefully be able to give it a swing in a week or so.

I have one question with respect to the compatibility with Windows. I have noted that several files (and a few directories) have been attached the string "Template", e.g. Vector.H (in foam-extend-3.1) is now VectorTemplate.H (in foam-extend-3.2). Furthermore, I have found that "Time.[H,C]" has been renamed to "foamTime.[H,C]".

Is this revised naming scheme adopted, because of problems with the lack of case-sensitivity in Windows?

Thank you for your time,

Niels

P.S. I have succeeded to compile waves2Foam on foam-extend-3.2 with only minor efforts for crossVersionCompatibility. It has been surprisingly effortless, when one considers that foam-extend is now available on multiple operating systems.

[wyldckat]

Originally Posted by ngj

Is this revised naming scheme adopted, because of problems with the lack of case-sensitivity in Windows?

Quick answer: Pretty much due to Windows' limitation with file name case-sensitivity, but this also has some advantage for Mac OS X users, because the default file system format is also case-preserving as it is in Windows.
It's what they (Microsoft/Apple) call a "user friendly feature"... given that a lot of people don't care much about the file names and can easily end up with two files that only differ in the letter case, resulting in some bad user experiences...

edit: Sorry, don't what to give the idea of answering for Hrvoje, it's just that I'm very familiar with this topic and have been briefly monitoring from the outside how the port is being handled in foam-extend .

[hjasak]

Correct Bruno: we have now removed all name clashes, both within the same library or in cross-library linking.

We will re-do the lnInclude next and I am still reconsidering the move to hpp/cpp file naming. Would anyone be interested in building FOAM in Visual Studio, now that it is available for free?

Hrv

[wyldckat]

Regarding name clashes, I suggest you keep a look out for "src/foam/primitives/char/char.H", because I had issues with the system's "char.h" in the past

Originally Posted by hjasak

Would anyone be interested in building FOAM in Visual Studio, now that it is available for free?

It would certainly make debugging a lot easier in Windows... and probably some better binary optimizations... and to be able to build the "PV4FoamReader" plug-in to work with the official ParaView...

But I thought that it required ugly hacks in the source code and increase maintenance issues? Or is the latest MSVC now able to handle such a complex C++ code?

[markusrehm]

Hi Hrvoje,

the option of compiling OF in Visual Studio is an interesting option.

Markus

[frantov]

Hello
Im trying to install Immersed Boundary on MacOsX

I didn't understand what were the specific instructions for Mac.

So far I did

mkdir -p $FOAM_RUN
cd $FOAM_RUN/..
git clone git@github.com:wyldckat/ImmersedBoundary.git ImmersedBoundary
cd ImmersedBoundary
git checkout fe31
cd src
./Allwmake

and Im getting this error:


make: *** [Make/darwinIntel64Gcc46DPOpt/immersedBoundaryEpsilonWallFunctionFvPatchScalarFi eld.o] Error 1
make: *** [Make/darwinIntel64Gcc46DPOpt/immersedBoundaryOmegaWallFunctionFvPatchScalarFiel d.o] Error 1
make: *** [Make/darwinIntel64Gcc46DPOpt/immersedBoundaryWallFunctionFvPatchFields.o] Error 1

Any clues?

Thanks

[wyldckat]

Originally Posted by frantov

Im trying to install Immersed Boundary on MacOsX

Quick questions:
Which foam-extend version are you using? Because if you are using foam-extend 3.2, then you do not need to use the code that is meant for foam-extend 3.1.

The other question is this: If you are using foam-extend 3.1, then those error messages appear only at the end; therefore, what are the first error messages?
To get a complete log of the build procedure, run:

./Allwmake > log.make 2>&1
gzip < log.make > log.make.gz

Then you can attach the file "log.make.gz" to your next post.