Porting

As we started with the porting of OpenFOAM Symscape released some patches to build a windows version of OpenFOAM with a mingw cross compiler. As these patches among other things abstract the OS specific things into a separated library we have based our work on these patches. The patches and a description of them are available at the Symscape webpage: www.symscape.com/openfoam-on-windows.
We have categorized the porting issues in to three scopes, the Build System, which also contains files system issues, OS specific things and compiler and linker issues. The issues are described together with our solution.

• Build System:

1. Microsoft Windows file system NTFS is not fully case sensitive. Because in the OpenFOAM sources some filenames only differ in a case sensitive environment, it is necessary to rename those files. To unpack the OpenFOAM source archive on a Windows computer the python program cstar has been written. cstar (case sensitive tar) is based on the tar module, automatically resolves the name clashes and generates a list of renamed files with a mapping of their old to their new names. All include directives have been adapted to the new file names with the python script fixincludes.py.
2. Microsoft Windows does not support soft links for non administrative users. The OpenFOAM build system, which are shell scripts and wmake use soft links extensively to enable short include paths and include directives. As a quick fix for this, in all C/C++ source files, all include directives have been change relative to the solution root. This leads to longer include directive but keeps the include paths manageable.
3. The longest pathname supported by Microsoft Windows is 256 characters long. The directory structure of OpenFOAM is quite deep, but fortunately does not exceed this limit. The sources cannot be unpacked in an already nested place like a subdirectory of the user’s profile. Instead they must be deployed to a path with a short name, e.g. C:\openfoam.
4. The OpenFOAM lex files can be either translated to C files with Flex for Windows from the GnuWin32 project or they have to been translated in a Linux environment. Because this port is only a proof of concept, we translated them with the Linux version of Flex, which worked fine.
5. The build tool “wmake” which is used by OpenFOAM is available for Microsoft Windows (see openwatcom) but we decided to stick to the Microsoft tool chain, because OpenFOAM does use a lot of shell scripts on top of wmake. To create Visual Studio projects, the python script createVSProject.py reads the wmake files files and options from the libraries and applications and creates a corresponding Visual Studio project for each target.

• OS specific Issues:

The most OS specific issues have been resolved by the patches from Symscape. There are however a few things left:

1. On Microsoft Windows some typedefs and defines are missing. To resolve this issue the header types.h has been added to the OSSpecific project. The needed typedefs and defines have been taken from the headers of Microsoft SUA.
2. Microsoft Windows does not come with an implementation of gettimeofday: The gettimeofday implementation from http://www.openasthra.com/c-tidbits/gettimeofday-function-for-windows/ has been added to clockTime.Cpp in the OSSpecific project.
3. The device /dev/null is only available on UNIX like platforms but it is used by some OpenFOAM modules. We have added the template ofnullstream to the OSSpecific project and replaced the few usage of /dev/null with ofnullstream by hand.

• Compiler/Linker Issues:

The port of OpenFOAM from gcc to the Microsoft Visual Studio 2008 compiler has caused various compiler errors. The fixes for them can be extracted from a patch file which will be available on request. The name resolution of the Microsoft compiler however was a reoccurring problem. To give two examples:

1. There was an ambiguous access to IOdictionary in dynamikInkJetFvMesh.C

2. There have been problems with different instantiations of HashTable (HashTableI.H, HashTable.H, HashTable.C), e.g. operator()() cannot be distinguished between different types. This has lead to linker errors because the symbols got stripped during linking.

The solution for this compiler errors have been: explicit specilization, explicit inlining or being more explicit with the names, e.g. calling a constructor with IOdictionary:: IOdictionary instead of IOdictionary.

Other Issues that are worth mentioning are:

• Visual Studio 2008 does not support the C99 feature variable length arrays.

The uses of variable length arrays have been replaced with alloca, malloc and free calls, e.g. in processorLduInterfaceTemplates.C.

• OpenFOAM uses the following keywords of the Visual Studio 2008 C++ compiler: near, far (e.g. in treeBoundBox.C) and DELETE (in topoSetSource.C, ...)

The entities with the name of a compiler keyword have been renamed.

• Microsoft does not deliver bcrt (Cube root) in math.h with the C standard library.

We use bcrt from the Intel Math Kernel Library.

• Porting shared libraries from UNIX/Linux to Windows is a lot of work, because all symbols of a shared library need to be explicitly exported for the Microsoft tool chain.

To bring this proof of concept we first build a statically linked version. The major drawback of this approach is less flexibility for user routines.

• The static linked version has introduced a new problem, because the linker does not include unreferenced objects into the executable and OpenFOAM uses dynamic run time selection tables to select solvers. Therefore some modules needed for our test case have not been available during execution.

To make our test case run we have added the needed but striped object files explicitly to the linker command line to force the inclusion into the executable. This step however needs to be repeated for all cases which use different modules, so a dynamically linked version is absolutely necessary.