[incompressible]

How can I interlace my own OpenFOAM code with ITK?

Assume that I simply take an existing OpenFOAM code (such as icoFoam) and want to extent it using some routines for which I need to write own cpp classes. One of these cpp classes include ITK routines in order to call functions related to image processing. How do I have to change the Make/files or Make/options in order to be able to build and run all together? Checking ITK tutorials, I see that they only use cmake writing some CMakeList.txt files, so there was no example how to do it with wmake or how to bring it to run together with own OpenFOAM developments. I tried to call 'cmake' as a command in Make/files and tried to build with wmake, but no success so far. Any ideas?

Many thanks.

[tomislav_maric]

Hi,

I have encountered the same problem when I wanted to use Google Test. If you just use 'wmake' and provide the appropriate input in 'Make/options', you will be able to compile OpenFOAM applicaitons and classes against any other external library, here is what I did for Google Test:

EXE_INC = \
    -I$(SOME_VARIABLE)/src/lnInclude \
    -I$(LIB_SRC)/finiteVolume/lnInclude \
    -I$(SOME_VARIABLE)/third-party/gtest/include 

EXE_LIBS = \
    -L$(SOME_VARIABLE)/third-party/gtest/build \
    -lgtest \
    -lfiniteVolume

Basically, you need to introduce the include directory where ITK headers (or links to headers) are stored with the '-I$' that then uses either some variable, or the full path. Also the linker needs to be aware of the ITK binaries, which is what you can achieve by providing the directory with '-L$' option. Afterwards, you need to specify the library linked to - 'gtest' in the example above. That's it. I didn't switch the build system, there is no need, you can do quite well with wmake.

[incompressible]

Hi there,

Thank you very much for your response! That solved the problem very well. It was a little bit hard though, since there has been too many missing libraries, certain other Unix related issues and together with very little to almost non-descriptive error messages. But after some painfully amount of days, the issue could be resolved, in the meanwhile getting to be a fully developed Unix-Freak . I can almost hack now .

[tomislav_maric]

Hi, I'm glad it helped!

The problem with the almost unreadable errors you probably saw yourself when libraries are not linked properly is that symbol lookups fail - the compiler tries to find a function like:

void functionName(type argument, type2 argument2)

and you see something like

undefined reference to 73Edcvoid7sesfunction2ctype13x_type2x32

In which case using 'c++filt' to unmangle the above messed up name might help, just FYI, maybe you'll need it in the future. The compiler mangles the names (function, classes, attributes, etc) because it uses the mangled names in the overload resolution process...

@hacking: I know what you mean, it takes time to get a hang of these things, just keep digging into that stuff and post here when you encounter problems that take more than half a day to tackle...

[elvis]

Hi,

unfortunately the guys that made the FreeFOAM seem to have stopped their projekt
+FreeFOAM is a fork of OpenFOAM®.
+the custom WMake build system used in OpenFOAM has been replaced by the excellent, cross-platform CMake, making it much easier to port FreeFOAM to new platforms.

[tomislav_maric]

Originally Posted by elvis

WMake build system used in OpenFOAM has been replaced by the excellent, cross-platform CMake, making it much easier to port FreeFOAM to new platforms.

Regardless of the build system - the idea is the same. Each build system specifies in one way or the other the location of the class/function/blah declarations. It also requires the location of library binary code for linking against.

What incompressible tried to do at first can't work - using two build systems.

My suggestion is to use whatever build system your OpenFOAM version is using (wmake, cmake, boost.build, whatever), to build OpenFOAM applications and libraries. Likewise, one should switch to the build system of the other platform (in this case ITK) to build apps and libs that only make use of OpenFOAM headers / libraries within that platform.

[incompressible]

Originally Posted by tomislav_maric

Regardless of the build system - the idea is the same. Each build system specifies in one way or the other the location of the class/function/blah declarations. It also requires the location of library binary code for linking against.

Sure, but not exactly the truth. Besides the linkage of some libraries and paths of header directories, build systems can also be used to prepare certain other utilities, which makes it a little bit complicated to integrate something (such as ITK), which was mainly build with one build system (cmake), with something else (e.g OpenFOAM) using another build system (lets say wmake).

In ITK, for example, they use certain design patterns whose objects are created and prepared in their certain cmake files directly. In terms of a given try to what computer scientist call "information hiding", this should happen behind the knowledge of the user or they shouldn't care about how these objects are actually created. One example of such structures are the factory classes responsible to create and manage objects to handle, lets say, different file formats such as PNG, JPEG, TIFF etc. Now, if an ITK user, whatever her own ITK application she prepares with cmake, loads a PNG image, she won't even now or realise the factory objects that does the job. As she builds her application with cmake, one of the main cmake files of ITK are called automatically, which creates these objects. However, if an OpenFOAM user, such as me, now goes forward and tries to integrate ITK platform to his OpenFOAM framework, he will just wonder why his images cannot even be loaded at all. So it is not "enough" to just put the libraries and includes to the wmake files, but all necessary factory objects now have to be created manually in own code, as long as one does not follow the path given by cmake builds. Therefore the statement with "the same idea regardless of the build system" might not always be valid, but in general of course the truth.

Maybe its a little bit more clear now, why I originally tried to call something like 'cmake' from wmake with a hopeless hope to be able to build another application and dynamically link it to OpenFOAM framework without having to perform two separate builds.

[tomislav_maric]

However, if an OpenFOAM user, such as me, now goes forward and tries to integrate ITK platform to his OpenFOAM framework, he will just wonder why his images cannot even be loaded at all. So it is not "enough" to just put the libraries and includes to the wmake files, but all necessary factory objects now have to be created manually in own code, as long as one does not follow the path given by cmake builds.

Wow, OK, I definitely was not aware of that. With Google Test it went smoothly as soon as I have let the build system know where the headers/binaries are.

IMHO, to me this seems like a strange approach to set up an object factory. I don't see the logical connection between the build system and the factory at all... If a generic factory is used, I would expect the client code (some ITK/OpenFOAM application cpp file) to instantiate the appropriate factory at compile time. On the other hand, if something like OpenFOAM's run-time selection is used, then the object generation will be bound to the class hierarchy and governed by configuration (input) files - are they using make files for this in ITK? Binding it to the build system just sounds a bit weird to me... but maybe it's done this way because there are no case directories like for OpenFOAM where you can then shove the input data for the run-time selection of the factory. Anyway, no wonder it took you some time to set that up.

Was the factory a pointer to the base factory class in the client ITK code, and you kept getting run-time errors? Segfaults since the concrete factory is not initialized would be my first guess. That must have been 'extremely fun' to find.