Note: this patch has been obsolete for a long time because of the libs-entry int the controlDict. This page is only kept for nostalgic reasons
Contents
1 Motivation
The runtime-selection-tables of OpenFOAM offer a very flexible way to select different implementations of a model (turbulence, BC, ..). Usually the implementations are provided by the libraries linked at compile time. If a user wants to add his own implementations of a model (without modifying the original solvers) he can do so by adding the sources to the foamUser-library and recompiling that library.
The problem with this approach is that there is only one such library and it might contain
- models (BCs) from different unrelated projects
- models that contradict each other
- models that are only of interest for a very limited range of cases
- it is difficult to extract specific models and pass them on (without checking for possible dependencies before and after)
The aim of this patch is to provide a mechanism that makes it possible to specify additional libraries in the case that uses them without modifying the original solvers/libraries.
This would make it possible to have libraries that contain
- boundary conditions
- turbulence models
- etc
that are problem-specific and pass them around.
2 Application of the patch
The patch patch can be applied to a vanilla OpenFOAM 1.3 source by doing this:
cd $FOAM_SRC/OpenFOAM cat plugIn.OpenFoam1.3.patch | patch -p0 -b wmake libso
(the -b-option is not necessary if you trust the provider of the patch. I use it)
3 Usage
If there is no dictionary constant/plugInDict in the current case available the behaviour of OpenFOAM is unchanged.
If there is a dictionary constant/plugInDict then from this dictionary a list of dynamic libraries is read. OpenFOAM then attempts to load all these libraries into memory (libraries are looked for according to the usual rules of the operating system - LD_LIBRARY_PATH etc). If one library is not found the application fails. If all libraries can be loaded the application continues as usual, but all the runtime-selectable models contained in the library are available.
The constant/plugInDict looks like this:
/*---------------------------------------------------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 1.3 | | \\ / A nd | Web: http://www.openfoam.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; root ""; case ""; instance ""; local ""; class dictionary; object plugInDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // libraries ( compressibleFluxBCs ); // ************************************************************************* //
4 An example
An example would be the addition of mass-flux and heat-flux and using it with rhoTurbFoam.
4.1 The library
The library implements three boundary conditions:
- a mass flux that is specified as on the patch
- a mass flux that is specified for the complete patch as
- a heat flux that is specified on the patch
The only dependence is that a compressible solver is used and a turbulence model.
This library only serves as an example and should not be seen as the best possible implementation of these BCs
4.2 The case
This case is derived from the tutorial case forwardStep. The inflow is specified by using the mass-flow boundary condition, the obstacles emits energy using the heat flux condition.
If the patch was applied and the library was compiled (and can be found on the LD_LIBRARY_PATH) it can be started using an unmodified rhoTurbFoam:
blockMesh . fluxForwardStep rhoTurbFoam . fluxForwardStep
5 Technical discussion
Some additional comments on the patch:
- the idea for this patch comes from dynamicFvMesh-library which does something similar
- there might be a better place to hook into that argList, but it seemed the earliest time where everything necessary (name of the case-directory) was available.
- the patch has been tested with Linux (64 bit) and Mac OS X. Apart from the extension of the dynamic-libraries there are no OS-dependencies
- I'm well aware that unwise usage of this extension can lead to some kind of DLL-hell (which is the current version? where is it?), but adding source files to foamUser can lead to a similar C-file-hell.
- The patch works for parallel runs, too
6 History
- 2006, Oct. 18: Initial upload
- 2006, Nov. 16: On parallel runs the processors looked for the Dictionary in processorX/constant. This has been fixed