A collection of libraries and tools that let the user handle OpenFOAM-data based on expressions
This file gives an overview of swak4Foam
and a history of the
features. It is not a canonical documentation.
This file is written in the mighty org-mode
(see
http://orgmode.org/) a markup/outline-mode for (X)Emacs. Using this
mode it can be easily (using 3 keystrokes … it’s Emacs) to PDF or
HTML to make it more readable (and add a table of contents).
Please don’t try to “beautify” it with any other text editor as
this will surly mess up the markup (and keeping the file
org-compatible outside of the org-mode
is a pain in the neck.
Bernhard Gschaider (bgschaid@ice-sf.at)
Bernhard Gschaider (bgschaid@ice-sf.at)
In alphabetical order of the surname
- Martin Beaudoin
trackDictionary
insimpleFunctionObjects
- Martin Becker
- The
potentialPitzDaily
-case (demonstrating a problem withgroovyBC
) - Oliver Borm
patchMassFlowAverage
insimpleFunctionObjects
- Peter Keller
sprinklerInlet
-case- Martin Kroeger
mtv
surface writer insimpleFunctionObjects
- Andreas Otto
- fixed the
circulatingSplash
-case - Alexey Petrov
pythonFlu
-integration- Bruno Santos
-
- Compilation with Intel compiler and Mingw
- Rewrite of
mybison
andmyflex
to allow parallel compilation withWM_COMPPROCS
If anyone is forgotten: let me know
According to the commits in the mercurial
-repository (and
the repositories of the projects from which swak emerged)
contributors are (ordered by the year of their first contribution):
- 2006-2013 Bernhard F.W. Gschaider <bgschaid@ice-sf.at>
- 2008 Hannes Kroeger (hannes@kroegeronline.net)
- 2008-2009, 2012 Martin Beaudoin, Hydro-Quebec (beaudoin.martin@ireq.ca)
- 2010 Marianne Mataln <mmataln@ice-sf>
- 2010 Oliver Borm (oli.borm@web.de)
- 2011 Alexey Petrov <alexey.petrov.nnov@gmail.com>
- 2011 Petr Vita <petr.vita@unileoben.ac.at>
- 2012 Bruno Santos <wyldckat@gmail.com>
- 2013 Georg Reiss <georg.reiss@ice-sf.at>
See: http://openfoamwiki.net/index.php/contrib/swak4Foam
- Version 2.0, 2.1 or 2.2 of OpenFOAM (a version that works with 1.6,
1.6-ext and 1.7 is available separately)
- The
finiteArea
-stuff will probably work with version 2.0-ext (once that is available)
- The
- the compiler generators
bison
andflex
- bison
swak4Foam
is known to work withbison
version 2.4 and higher. Version 2.3 compiles but the plugin-functionality does not work correctly- flex
- since the introduction of the plugin functions at least
a flex version of
2.5.33
is required (2.5.35
is the lowest confirmed version)
Both of these are mainstream packages (they are for instance needed
to compile gcc
) and should exist on every Linux distribution. Use
the package manager of your distribution to install them and only
if the compilation process of swak4Foam
complains about too low
versions try to install them from other sources.
swak4Foam
tries to keep the requirements on these as low as
possible and sometimes lower versions than the ones reported may
work. If they do please report so.
The version of bison can be checked with
bison -V
The version of flex with
flex -V
wmake all
at the base directory should build all the libraries and tools.
Rerun the command to make sure that there was no problem with the compilation (this should be quite fast and only report libraries being created and some administrative stuff)
Some features (currently only the Python
-integration may need
third party software. The paths to these packages can be configured
in a file swakConfiguration
(an example file
swakConfiguration.example
is provided). If that file is not
present these unconfigured features will not be compiled.
Environment variables that can be set in this file are:
- SWAK_PYTHON_INCLUDE
- Path to the
Python.h
file of the usedpython
-installation - SWAK_PYTHON_LINK
- Options to link the
python
-library to the library for thepython
-integration - SWAK_USER_PLUGINS
- A list of paths separated by
semicolons. These are the directories of libraries with
function-plugins. They are compiled in the course of the
normal
swak
-compilation. This makes sure that they are consistent with theswak
-release in the case of an update - SWAK_COMPILE_GRAMMAR_OPTION
- Additional compiler switches for
the C-files generated by
bison
. Usually used if the default optimization switches are too aggressive and compilation takes to long (then a value like-O0
would for instance switch off all optimizations)
With older versions of 2.0.x (or 2.0 or 2.0.1) it is possible that
the compilation of swakCodedFunctionObject
will fail. In that
case remove the last parameter to the
codedFunctionObject
-constructor in swakCodedFunctionObject.C
(it is clearly marked by a comment)
Note: This section is very special and won’t be needed by most people
The library libswakPythonIntegration.so
links against a specific
version of the python library. In certain circumstances (for
instance the OS of the cluster is different from the one that swak
was compiled on) this python-version is not available on the
target machine. While all other parts of swak will work the
python-integration won’t load on the target machine. To fix this
problem a workaround is provided:
The script maintainanceScripts/makeSpecialPythonLibrary.sh
compiles a special version of the libswakPythonIntegration.so
that is identified by an additional suffix (for instance the
suffix Cluster
makes a file
libswakPythonIntegrationCluster.so
). That script has to be run
on the target system and needs 3 parameters:
SWAK_PYTHON_INCLUDE
SWAK_PYTHON_LINK
- The suffix
For instance
./maintainanceScripts/makeSpecialPythonLibrary.sh -I/opt/local/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 "-L/opt/local/lib -lpython2.5" Version2.5
compiles a version for an old python.
To enable the python-integration in libs
in controlDict
both
python-integrations have to be specified. One of them will fail on
each machine (because the required python-library is not there),
the other one will provide the python-functionObjects.
Note: the special libraries won’t be updated automatically on the target system. Doing so is the responsibility of the user.
If the libraries and utilities are considered stable and the should
be available to everyone (without having to recompile them) the
script copySwakFilesToSite.sh
in the directory
maintainanceScripts
can be used to copy them to the
global site-specific directories.
The script removeSwakFilesFromSite.sh
in the directory
maintainanceScripts
removes all these files
from the global directories. The removeSwakFilesFromLocal.sh
does
the same for the user directories (this makes sure that no
self-compiled version shadows the global version (which would
lead to strange results)
There is a Makefile
attached. make globalinstall
compiles swak4Foam
and installs it into the global directories
Note: Due to the order in which library direcories are searched
for with -L
a global installation might break the
compilation. If you don’t know what this means: don’t attempt a
global installation
The command build dpkg
builds a Debian/Ubuntu package for
the currently enabled OpenFOAM-package. Note:
- it is assumed that the currently used OF-version was also installed by the package manager
- the
dev
package is built but poorly maintained
Changes in the packaging should be done in the branch
debianPackaging
of the Mercurial-repository and later be
merged to the default
-branch.
Packaging for OpenFOAM 2.x should be done in the branch
debianPackaging_2.x
Note: Due to the problem described with the global installation it might be necessary to deinstall a previously installed package to successfully build a new package
Collection of Libraries
The basis of swak4Foam
: the expression parsers with the logic to
access the OpenFOAM data-structures.
None of the other software pieces compile without it.
Also defines a subclass to DataEntry
that uses
swak
-expressions and a function object initSwakFunctionObject
that might be used if this fails
A collection of function objects that was previously separately available at http://openfoamwiki.net/index.php/Contrib_simpleFunctionObjects.
Provides consistent output of values (on patches and fields) and more.
Implements the infamous groovyBC
. A boundary condition that
allows arbitrary expressions in the field-file
Function objects that have no additional requirements. Mainly used for manipulating and creating fields with expressions
- addGlobalVariable
- Adds a variable to a global swak-namespace. Mainly used for debugging and resolving issues where a variable is needed in a BC before it is defined.
- expressionField
- Create a new field from an expression
- clearExpressionField
- Erase a field created with
expressionField
- manipulateField
- Modify a field in memory
- createSampledSet
- Create a sampled set that can be used by other swak-entities (mainly boundary conditions)
- createSampledSurface
- Create a sampled surface that can be used by other swak-entities (mainly boundary conditions)
- swakCoded
- Child of the
coded
-functionObject that can read and write global variables from and to swak-namespacesAssumes that the
SWAK4FOAM_SRC
environment variable is set to theLibraries
-directory of theswak4Foam
-sources - solveLaplacianPDE
- Solve the Poisson equation
\begin{equation}
\frac{∂ ρ T}{∂ t} - ∇ λ ∇ T =
Sexpl + Simpl T
\end{equation}
for
- solveTransportPDE
- Solve the transport equation
\begin{equation}
\frac{∂ ρ T}{∂ t} + ÷(φ,T) - ∇ λ ∇ T =
Sexpl + Simpl T
\end{equation}
for
- addForeignMeshes
- this allows specifying new foreign
meshes. These can be used in subsequent function-objects or
other swak-expressions on
internalFields
- foreignMeshesFollowTime
- this allows specifying a list of meshes whose time is set to the current time of the running case
Function objects based on the simpleFunctionObjects
-library
(which is a prerequisite for compiling it).
Evaluate expressions and output the results
These classes allow to manipulate the solution. To use these the solver has to be modified.
- expressionSource
- Field that is calculated from an expression. To be used as source-term or coefficient in some solver
- forceEquation
- force an equation to fixed values in selected locations. Has to be used after constructing the equation and before solving
These sources are based on basicSource
and can be used
without a modification of the solver (they are only available in
the 2.x version):
- SwakSetValue
- sets values according to a mask or the
mechanism provided by
basicSource
- SwakExplicitSource
- Uses the calculated source term on the right hand side of the equation
- SwakImplicitSource
- Uses a calculated scalar-field to add an implicit source term (source is without the actual field)
topoSources
for cellSet
and faceSet
. Can be used with the
cellSet
and faceSet
-utilities
Implements parsers for the finiteArea
-stuff in 1.6-ext. Also
implements groovyBC
for areaField
and expressionField
and
other function objects
Collection of boundary conditions that give standard boundary conditions the possibility to use expression for the coefficients
Contributions to this library are explicitly encouraged. Please
use the Mercurial-branch groovyStandardBCs
to groovyify
standard boundary conditions.
Embeds a Python
-interpreter.
pythonIntegrationFunctionObject
- Executes
Python
-code at the usual execution times of functionObjects. The interpreter keeps its state
This library is only compiled if the paths to the Python-Headers
are configured in the swakConfiguration
-file (see above)
Function objects that allow the easy addition of lagrangian
clouds to a case. No other libraries from swak4Foam
are needed
for this
Additional searchableSurfaces
(for use in snappyHexMesh
)
which include boolean operations for other surfaces and
coordinate transformations
Driver for functionObjects
that implemented entirely in Python
using the pythonFlu
-library
Directory with a number of libraries with function-plugins:
- swakFacSchemesFunctionPlugin
- functions with selectable discretization schemes for FAM (only used in 1.6-ext)
- swakFvcSchemesFunctionPlugin
- functions with selectable schemes for FVM
- swakLocalCalculationsFunctionPlugin
- calculations that are local to a cell (Minimum of the face values or so)
- swakMeshQualityFunctionPlugin
- calculate mesh quality criteria like orthogonality, skewness and ascpect ratio
- swakRandomFunctionPlugin
- different random number distributions. Currently only exponential
- swakSurfacesAndSetsFunctionPlugin
- calculates distances from
sampledSurfaces
andsampledSets
and projects calculated values from these onto a volume field - swakThermoTurbFunctionPlugin
- Access functions from the thermophysical model and the turbulence model in the current region. Loads the model only if necessary
- swakTransportTurbFunctionPlugin
- Same as above but for incompressible models
- swakLagrangianCloudSourcesFunctionPlugin
- Functions that get informations like source terms from clouds of particles (due to technical reasons this works only for the regular intermediate clouds)
- swakVelocityFunctionPlugin
- Functions that work on the flow field (currently only the local Courant-number)
Utility that allows creation and manipulation of files with expressions
Utility like funkySetFields
for areaFields
(only works with
1.6-ext)
Sets any field on a boundary to a non-uniform value based on an expression.
Acts without deeper understanding of the underlying boundary condition
Utility to quickly test whether a groovyBC gives the expected results. Writes the specified fields with the applied boundary condition but doesn’t do anything else.
Can be used for other BCs as well
Evaluates expressions that are listed in a dictionary using data that is found on the disc and prints summarized data (min, max, average, sum) to the screen
Calculates the offsets
-entry in the polyMesh/boundary
-file
according to the specification in a dictionary. Only needed if you
have mapped patches and the regular uniform offset is not enough
for your purposes
If not otherwise noted cases are prepared by a simple
blockMesh
-call.
Note: All the cases here are strictly for demonstration purposes and resemble nothing from the ‘real world’
The old groovyBC
-Demos
- Solver
- pisoFoam
- Also demonstrates
manipulateField
,expressionField
andclearField
from theswakFunctionObjects
.patchExpression
fromsimpleSwakFunctionObjects
.solveLaplacianPDE
andsolveTransportPDE
for solving equations,pythonIntegration
with calculations usingnumpy
- Solver
- solidDisplacementFoam
- Solver
- interDyMFoam
- Solver
- pimpleDyMFoam
- Also demonstrates
swakExpression
withsurface
. Due to a problem described below this currently doesn’t work
- Solver
- pimpleFoam
- Mesh preparation
- Execute the script
prepare.sh
in that directory (requires PyFoam: if not installed change in theboundary
-file the type of thedefaultFaces
towall
)
- Solver
- pimpleFoam
- Demonstrates
- Delayed variables to simulate an inflow that depends on the value of the outflow
- Solver
- chtMultiRegionFoam
- Mesh preparation
- Execute the script
prepare.sh
in that directory - Also demonstrated
patchExpression
andswakExpression
fromsimpleSwakFunctionObjects
.
- Solver
- interFoam
- Also demonstrates
- Usage of a
sampledSet
defined in thecontrolDict
do determine the average filling height. Also stored variables for not switching back once the criterion is reached. Global variables defined by a function object
- Solver
- interFoam
- Description
- Winner of the
swak4Foam
-competition at the 6th OpenFOAM-Workshop (2011). By Peter Keller
- Solver
- potentialFoam
- Description
- Demonstrates the use of
groovyB
withpotentialFoam
(also a problem connected with that). Provided by Martin Backer
Example dictionaries for funkyDoCalc
Example dictionary for funkySetFields
Example dictionary for funkySetBoundaryFields
. Sets nonsense
boundary conditions for the world famous damBreak
-case
Demonstrates usage of expressionSource
Due to differences in the original interFoam
-solver this doesn’t
work on certain OpenFOAM-versions (most specifically
1.6-ext
). The current solver works with 2.1. For older
OF-versions use the sources labeled _pre2.1
.
The only modifications to the original solver are found at the end
of createFields.H
and in UEqn.H
(the added source terms).
Demonstrates usage of forceEquation
Due to differences in the original interFoam
-solver this doesn’t
work on certain OpenFOAM-versions (most specifically
1.6-ext
). The current solver works with 2.1. For older
OF-versions use the sources labeled _pre2.1
.
The only modifications to the original solver are found at the end
of createFields.H
and in UEqn.H
(the fixing of the velocities).
Slightly modified version of interFoam
. Adds a source term to
the momentum equation. The source term is an expression that is
defined at run-time
Demonstration case for it.
- Preparation
- Run the script
prepare.sh
to prepare the case
Demonstration of the finiteArea
-stuff that works with 1.6-ext
Variation of surfactantFoam
that adds an expressionSource
Demonstration case
- Preparation
- Use
blockMesh
andmakeFaMesh
- Solver
surfactantFoam
(without source term) orswakSurfactantFoam
- Demonstrates
- FAM-specific
swakExpressions
andgroovyBC
(as well as theexpressionSource
)
Cases that don’t have a groovyBC
- Solver
- rhoPorousMRFSimpleFoam
- Mesh preparation
- Execute the
makeMesh.sh
-script in that directory. If you want to run in parallel call thedecomposeMesh.sh
-script with the number of processors as an argument - Demonstrates
- Usage of the
swakTopoSources
. Compares different approaches to evaluating with theswakExpression
-functionObject. Also an example dictionary that demonstrates the use offunkyDoCalc
. Demonstrates “live” comparing to another case using foreign meshes
- Solver
- rhoPorousMRFPimpleFoam
- Mesh preparation
- Execute the
makeMesh.sh
-script in that directory. If you want to run in parallel call thedecomposeMesh.sh
-script with the number of processors as an argument - Demonstrates
- The same as
angledDuctImplicit
but also the output of temporal changes
- Solver
- interFoam
- Case preparation
- run the supplied script
prepareCase.sh
- Demonstrates
- Usage of a sampled surface to track the interface in a VOF-simulation
- Solver
- interFoam
- Case preparation
- run the supplied script
prepareCase.sh
- Demonstrates
- Emulate a “moving gravitation” by using the
manipulateField
-functionObject to recalculategh
andghf
- Solver
- interFoam
- Case preparation
- run the
prepareCase.sh
-script - Description
- The case described on the slides of the
talk about
swak4Foam
at the OSCFD-conference 2012 in London - Demonstrates
- Boundary conditions, function objects, global variables and delayed variables
A 2D-variant of the above case
Demonstrate the integration of Python
. Mostly using PyFoam
but
also with pythonFlu
- Solver
- simpleFoam
- Demonstrates
- Usage of
PyFoam
to manipulate thefvSolution
-file during the run (possible application: unphysical initial conditions cause the run to fail during startup with “normal” relaxation values)
- Solver
- simpleFoam
- Demonstrates
- Usage of the
pythonFlu
-integration to find the point where the recirculation behind the step ends. Also tries to plot the result using thematplotlib
-library
- Solver
- twoPhaseEulerFoam
- Demonstrates
- Usage of
PyFoam
to read the direction of gravity and feeding it into agoovyBC
via global variables - Case preparation
- Just call
funkySetFields -time 0
- Solver
- chtMultiRegionFoam
- Demonstrates
- Building the specification of function objects at run-time via a Python-script
- Solver
- simpleFoam
- Demonstrates
- Using a python-script to dynamically generate multiple function objects (sampled surfaces). Using stack-variables to calculate the results and write them. Using a stored stack-variable to monitor the pressure at a point and stop the run if the pressure didn’t change there for the last 50 iterations
Demonstrates working together with the coded
-stuff in OpenFOAM 2.0
Examples for the functionObjects
that can solve Partial
Differential equations
- Solver
- laplacianFoam
- Demonstrates
- The usage of the
functionObject
that solves the laplacian (Poisson) equation and (hopefully) that it gets the same result as the native solver - Case preparation
Allrun
-script is provided
- Solver
- scalarTransportFoam
- Demonstrates
- Solving additional transport equations
These examples test the source terms based on basicSource
. They
only work with OpenFOAM 2.x and all use the simpleFoam
-solver
- Demonstrates
- Fixing the values of the velocity in a region
with
SwakSetValues
- Demonstrates
- Implementing a simple porous plug by adding the
Darcy-term as a source term with
SwakExplicitSource
- Demonstrates
- Same as
pitzDailyWithExplicitPoroPlug
but with an implicit source term withSwakImplicitSource
Tests for the functionObjects that create and evolve a cloud of
particles (library simpleLagrangianFunctionObjects
)
- Solver
- replayTransientBC
- Mesh preparation
prepareCase.sh
-script- Demonstrates
- 3 clouds (kinematic, reacting, solidParticle). Loading of a thermophysical model with a functionObject. Plugin functions for information about the clouds
- Solver
- rhoPimpleFoam
- Demonstrates
- Thermo-cloud. Functions for lagrangian particles
Examples for the use of the simpleSearchableSurfaces
-library.
- Solver
- simpleFoam (alternatively use the
caseRun.sh
-script) - Case preparation
- Script
caseSetup.sh
is provided - Demonstrates
- Using the same STL-file more than once in a case by applying coordinate transformations. Note: the physics of this case are more than questionable as the frame of reference for both motorbikes is wrong
- Solver
- interFoam
- Case preparation
- Script
caseSetup.sh
is provided - Demonstrates
- Boolean operations on STL-files
- Solver
- electrostaticFoam
- Case preparation
- Script
caseSetup.sh
is provided - Demonstrates
- Boolean operations with regular surfaces
Physics of the case not as expected (charge-distribution)
Simple test cases for specific features. The names of the
directories should give you a hint what is tested there. Most of
them don’t need a real solver but replayTransientBC
or
scalarTransportFoam
.
Note: for some features these cases are the only example there is. Sorry
Testing of different seeds for the rand
-function. Also tests
the randFixed
-function
Undocumented scripts used for maintaining swak4Foam
. If you
don’t understand them, don’t use them
Additional documentation. Most written in org-mode
Current contents:
- swak4FoamReference
- Reference manual of swak4Foam. Especially concepts like expression syntax and parameters
The preferred place for bug reports is http://sourceforge.net/apps/mantisbt/openfoam-extend/search.php?project_id=10&sticky_issues=on&sortby=last_updated&dir=DESC&hide_status_id=90
A sourceforge-account is required for reporting
If you’re reporting a bug about the compilation please run
Allwmake
twice and only report the messages from the second
run. This makes analyzing the log easier as only the unsuccessful
commands will be reported.
If the problem seems to be a missing library rerun the compilation to make sure that there wasn’t a problem with that.
Contributions to to swak4Foam
are most welcome. If you want to
contribute clone the Mercurial archive of the sources
hg clone http://openfoam-extend.hg.sourceforge.net:8000/hgroot/openfoam-extend/swak4Foam
Change to the branch that you want to improve (usually default
)
and create a new branch
hg branch <branchName>
where <branchname>
is an easily identifiable name that makes the
purpose of the branch clear (for instance
bugfixWrongRandomFunction
or featureHyperbolicFunctions
). Don’t
work on the default
branch or any other branches that are not
“yours”. Such contributions will not be merged
Once development on the branch is finished export the relevant changesets with
hg export <nodeID>
(nodeID
being the ids of “your” changesets) and send them to the
maintainer (or attach them to a bug report on Manits). The changes
will be reviewed and merged into the default
branch (do not
attempt to do this yourself). Patches generated with hg export
make sure that all changes are attributed to the original developer
(you).
An alternative would be the bundle
command. Just do
hg bundle <bundlefile>
and then send the bundlefile
. This will include all commits
that are not in the upstream repository and will allow similar
inclusion in the upstream as export
.
Once you have proven by successfully submitting changesets via hg
export
you can ask for write access to the mercurial repository.
Only if you got through Mercurial it can be ensured that your contribution is recognized (if you want to stay anonymous send patches).
These topics may be “new” for the average OF-developer:
- Mercurial
- A short tutorial on this can be found at
http://mercurial.selenic.com/guide/. If you already
know
git
the http://mercurial.selenic.com/wiki/GitConcepts may be enough for you - bison/flex
- This pair of compiler generator tools generate the
parsers for the expressions. Google for a tutorial
that looks promising to you.
For a short example that shows how a new function was added to two parsers have a look at this changeset that added the
cpu()
-function to the field and the the patch-parser (usually you’ll have to write a new method for the driver too):
hg diff -c 8604e865cce6
Currently the main branches are:
- default
- The main branch. This is the brancht that the general public will receive. It compiles under 1.7 and 1.6-ext
port_2.0.x
- The branch that compiles under OpenFOAM 2.0. This
will eventually become the
default
-branch - debianPackaging
- Branch for generating new Debian-packages of
swak4Foam
. If somebody wants to “inherit” this: contact the maintainer - finiteArea
- In this branch the things for the
finiteArea
-discretization (only present in1.6-ext
) is developed. Usually gets merged back into thedefault
-branch once a feature is completed
As an experimental feature distributed bug-tracking was introduced
using the Artemis-extension for Mercurial (see
http://hg.mrzv.org/Artemis/
). An up-to-date version can be
installed by
hg clone http://hg.mrzv.org/Artemis/
somewhere and installing the plugin by editing .hgrc
.
This is not the official bug-tracker for swak4Foam
. It is used
for keeping track of new features that are to be introduced to
swak4Foam
and may be discontinued if the experiment proves to be
unsuccessful.
swak4Foam
is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version. See the file COPYING in this directory,
for a description of the GNU General Public License terms under which
you can copy the files.
The following list is not complete. If the Artemis extension (see above) is installed then
hg ilist
gives a more up-to-date list
It seems that with moving meshes sampledSurfaces
don’t get
updated. This seems to be a problem with OpenFOAM itself (the
regular surfaces
-functionObject doesn’t get updated. This is
currently investigated
Apart from patches and internal fields the support for interpolation from cells to faces (and vice versa) is incomplete as well as point fields (although they are supported in the grammar)
This is especially evident for the funkyDoCalc
-example
Not really bugs, but stuff that bugs me
This is necessary because of bison
. Investigate possibilities to
replace these by tmp
and autoPtr
valgrind
reports some lost memory for stuff that is not directly
allocated by swak4Foam
(in OpenFOAM-sources)
Will investigate. Relevant places are marked by comments in the
code. Also the construction of sampledSet
seems to loose memory
Currenly problematice parts seem to be:
- update and
magSf
-calculation ofSampledSurface
(marked inSampledSurfaceExpressionDriver.C
) - Python interpreter (but no calls in swak were found in the stack-trace that could be responsible)
Before OpenFOAM 2.1 the inner product of two symmetric tensors was a symmetric tensor. Since 2.1 it is a general tensor. As the general treatment in the grammar would be confusing currently the this product was removed from the grammar and therefor will not be correctly parsed
The same problem that was mentioned in https://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=130 is also true for subsets. But as the interpolation is not implemented for most subsets this will be postponed
First Release
New release Most important changes
Now expressions for the field on a sampled surface can be
evaluated. All sampledSurfaces
offered by OpenFOAM now can be
used
The variables
entry (most notably used in groovyBC
and
swakExpression
) now can be a list of strings. This allows some
kind of “formatting” (one expression per line) and should improve
readability
These can copy the libraries and utilities to the global
installation (for those who think that the swak4Foam-stuff is
stable enough and want to ‘bless’ all users at their site with
it). Note that any local installation still takes precedence
(because $FOAM_USER_APPBIN
is before $FOAM_APPBIN
in the
$PATH
This allows the inclusion of other parsers with the regular
swak4Foam
parsers and include them seamlessly with the
variables
-mechanism for ‘externals’ (in other words: you can add
your own parser in a separate library without having to change
anything about the overall swak4Foam
, but it behaves as if it
was part of it)
Now there is support for the finiteArea
-library found in
1.6-dev. The support is found in a separate library
swakFiniteArea
. It has
- a parser
faField
forareaFields
- a parser
faPatch
for patches ofareaFields
- a variant of
groovyBC
for these patches - a computed source
faExpressionSource
- Function-object-variants for
areaFields
:clearExpression
,expressionField
andmanipulateField
. These work the same as theirvolField
-counterparts
See https://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=49
See https://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=44
New features and changes are (this list is not complete):
Like funkySetFields
for finiteArea. Also writes out a volume
field for easier post-processing
Makes it easier to use the groovyBC
-machinery for other boundary
conditions. Two standard boundary conditions were
groovified. Others may follow
If no simpleFunctionObjects
are present they can be downloaded
by a script.
Also scripts to handle global installations of swak4Foam
A class to force equations to certain values according to expressions
Utility does calculations on saved results and outputs single numbers (min, max, sum, average) to the terminal. Can be used for reporting or validity checks
Crude packaging for Debian
A single-argument function can be specified as a piecewise linear function. Basically works like timelines but the argument can be something else (not only the time)
Variables that store their values between time-steps. Applications are statistics or switches
Sampled sets can now also be used as en entity on which calculation is possible.
This is the first release that officially supports OpenFOAM 2.0
Also it is the first release that incorporates the
simpleFunctionObjects
-library
- These two functions now can receive an integer seed that determines the pseudo-randooom sequence generated by these functions
- Two functions
randFixed
andrandNormalFixed
were added. While the usualrand
functions generate a different result at every time-steps for these functions the pseudo-random sequence is determined only by the seed (not by the timestep)
Take the bigger/smaller of two fields. Helps avoid ?:
-operations
Application: If the results of the calculation are only needed in ParaView
- Use
autoPtr
for sets - Update sets that change in memory or on disc
Fixed by Petr Vita
Calculated boundaries were
- Packaging information for the currently used OF-version is
generated (allows a separate
swak
-package for every OF-version - Submission to launchpad added
Now install to FOAM_SITE_APPBIN/LIBBIN
Uses the usual -region
-option. Looks for a separate dictionary
in the system
-directory of that region
This can be switched on using the allowFunctionObjects
-option
Allows the execution of Python-Code in a functionObject
This feature is still experimental and the organization of the libraries is subject to change
It is now possible to define variables that are ‘global’: They can be read in any entity.
Currently these variables can only be uniform.
To access global variables the specification-dictionary has to
have a wordList
named globalScopes
. The scopes are searched
in that order for the names of global variables. Having scopes
allows some kind of separation of the variables
Adds a functionObject swakCoded
that extends the
coded
-functionObject to read and write global variables
Added a boundary condition than allows to only fix the
values. This should help to avoid problems with cases that don’t
like mixed
(on which the regular groovyBC
is based)
Two function objects that solve Partial Differential Equations during a run have been added:
- one that solves a laplacian (Poisson) equation
- one that solves the transport equation for a scalar
The relevant coefficients (including explicit and implicit source terms) can be specified using expressions
Added a script that takes the current sources, copies them into
the appropriate places of a OpenFOAM
-installation and slightly
rewrites them to compile in this place. What happens then
(committing them into the repository or just plain compilation)
is up to the maintainer
As many parts of swak4Foam
depend on it the
simpleFunctionObjects
have now been absorbed into
swak4Foam
. They can still be compiled on their own
If a variable is defined and the patch which it is defined on doesn’t have any faces the variable is reported on that processor as not existing and the whole run fails
Fixed according to a suggestion by Andreas Otto. Now runs again (used to crash some time-steps into the beginning)
The Allwmake
-script now checks for the correct bison-version
(and the existence of bison
) and fails if it doesn’t seem to be
the right one
To allow distinguishing different OF-versions as discussed in the
bug report
http://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=114
the Allwmake
-script now generates a header file
foamVersion4swak.H
that defines the symbols
FOAM_VERSION4SWAK_MAJOR
, FOAM_VERSION4SWAK_MINOR
and
FOAM_VERSION4SWAK_PATCH
- now can also produce surfaceFields
- full support of
tensor
,symmTensor
andsphericalTensor
- now can also produce edgeFields
No support for tensors yet
If necessary (for instance swakExpression
-functionObject) the
storedVariables
are written to disc (into a subdirectory
swak4Foam
of the timestep) and are reread at the start. This
allows consistent restarts (for instance if a flow was summed
using the variable) if the expressions stay the same.
Data files can now be written without brackets but each component on its own. The number of entries in the header is not adjusted
For drivers that don’t have access to a fvMesh
a default mesh
exists. This default mesh is defined by the first fvMesh
that
is used during the construction of any driver.
Definition of the default mesh can be forced using the
initSwakFunctionObject
(see the test case flowRateAngledDuct
)
Due to the refactoring of the FieldDriver
now phi
can be
specified by a general expression (instead of ‘only’ a
field-name)
Can write surfaceVector
and surfaceScalar
-Fields. Condition
has to be consistent
expressionField
and manipulateField
now can create or modify
surfaceFields
funkySetFields
and the function objects expressionField
and
manipulateField
now also work with the three tensor-types
If the expression evaluates to a surfaceField
then this is used
as a flag whether or not the face is in the faceSet
. If the
expression evaluates to a volScalarField
then the old semantic
applies (faces are in the set if one cell is true
and the other
is false
).
This only works for internal faces
If there is an entry globalVariables
then this dictionary is
used to set the variables
Calculates variables and then pushes them to a global namespace
New option added that generates a phi
field with value inletOutlet
happy
The functionObject dumpSwakExpression
dumps the complete
results of a swakExpression to file at each timestep. This
produces huge files and is therefor not endorsed
Add the options allowFunctionObjects
and addDummyPhi
to
execute functionObjects and add a phi
-field (for fields that
require these)
Based on the directionMixed
boundary condition this allows to
set a boundary condition as a Dirichlet-condition only in certain
directions while in the other directions it is a
gradient-condition
Boundary condition that imposes a jump in the value on a cyclic
boundary condition pair (based on jumpCyclic
). Only works for
scalar values
Setting the option outputFileMode
to csv
writes
CSV-files. The option-value foam
is the default (old style). The
option-value raw
writes the values delimited by spaces (no
brackets for vectors and tensors)
If a submesh is not yet in memory and the option searchOnDisc
is set, the mesh is automatically read into memory and kept there
The simpleFunctionObjects
-library now has a number of
functionObjects that allow the conditional execution of a list of
function objects.
These are
- executeIfExecutableFits
- if the name of the executable fits a regular expression the function objects are executed
- executeIfObjectExists
- if a named object exists (or alternatively: doesn’t exist) in the registry execute the function objects. Type checking also implemented
- executeIfEnvironmentVariable
- execute if an environment variable satisfies a certain condition (exists, doesn’t exist, fits a regular expression)
- executeIfFunctionObjectPresent
- execute if a specific functionObject is present. This can help prevent failures if a functionObject is missing for technical reasons
In addition the simpleSwakFunctionObjects
-library has
- executeIfSwakObject
- Evaluates a logical swak-expression. The results are either accumulated using logical or (if one value is true the result will be true) or logical and (all values have to be true)
The pythonIntegration
-library has
- executeIfPython
- Evaluates a Python-code-snipplet that returns a value. If this value is “true” in Pythons standards then the functionObjects are executed
simpleFunctionObjects
has an additional function object that
reads the direction of gravitation. The purpose is to assist
boundary conditions like buoyantPressure
that rely on it to
work. Best used together with conditional function objects (“If
g
is missing ....”)
Solve transport and laplacian equation
This is defined in the swak4FoamParsers
-library. The class
needs a default mesh defined to construct the driver. Definition
of the default mesh (if no other driver was constructed in some
function-object or by a groovyBC
) can be forced using the
initSwakFunctionObject
(see the test case flowRateAngledDuct
)
Similar to the surfaceFields
in funkySetFields
The Utilities
failed with the Intel-compiler. Compilation now
falls back to good old g++
Because the tokens were not defined in the flex
-files getting
tensor components with tensor.xx
did not work. Fixed
Because surfaceFields know no zeroGradient
the template
makeConstant
did not work
Change so that the field gets temporarily loaded to calculate the
gradient on the patch. Same for internalField
and
neighbourField
The reason is that groovyBC
usually doesn’t get evaluated
during construction. The reason is that it is hard to tell
whether all required fields are already in memory. The current
fix is a workaround: setting evaluateDuringConstruction
to
true
forces the BC to be evaluated during construction
Extra evaluation of boundary condition that should fix the
problem with calculated
patches causes funkySetFields
to fail
with stock boundary conditions if not all fields are present in
memory
This boundary condition will be removed in future releases
because the base class now supports the more general
DataEntry
-class for which a swak
-subclass exists
To distinguish the output of various instances of
functionObjects
from the simpleFunctionObjects
-library in
multi-region cases the screen-output is prefixed with the region
name. For the default region nothing changes. Directory names
stay the same as they are unambiguous anyway (they contain the
name of the functionObject)
For fields (not expressions!) the value at a previous timestep
can be gotten via oldTime(field)
if that information exists
(also for funkySetFields
if the corresponding file field_0
exists.
For fields that support it (basically volume-fields) there is
also a ddt
-operator that calculates the explicit
time-derivative (if information about the last timestep exists)
Currently implemented for
- internalFields
oldTime
andddt
- patch
- only
oldTime
- cellSet,cellZone
- only
oldTime
- sampledSurface,sampledSet
- only
oldTime
- faceSet,faceZone
oldTime
- internalFaFields
oldTime
andddt
- faPatch
- only
oldTime
If there is no old time value stored and in the parser dictionary
the parameter prevIterIsOldTime
is set, then the previous
iteration value is used as the old time.
Based on the directionMixed
boundary condition this allows to
set a boundary condition as a Dirichlet-condition only in certain
directions while in the other directions it is a
gradient-condition
Note: this should have been in the last release but was forgotten to merge into the default branch
Boundary condition that imposes a jump in the value on a cyclic
boundary condition pair (based on jumpCyclic
). Only works for
scalar values
Note: this should have been in the last release but was forgotten to merge into the default branch
The functions minPosition
and maxPosition
return the position
of the minimum or the maximum of a scalar field
This is implemented for all field types
Now can read and generate pointFields.
Detailed features (apart from the standard symbols) are:
- Function
point
generates a constantpointScalarField
- Function
pts()
returns apointVectorField
with the point positions - Functions
pzone
andpset
generate logical fields according to existing pointZones or pointSets - Functions
interpolateToCell
andinterpolateToPoint
interpolate from pointFields to volFields and from volFields to pointFields
Utilities and functionObjects affected by this are
funkySetFields
- new topoSource
expressionToPoint
expressionField
andmanipulateField
now can deal with pointFields
The faField
-parser now supports tensors, symmetric tensors and
spherical tensors.
Not all operators are supported because the are not instantiated in 1.6-ext
These variables are added in the namespace to ease the writing of Python-code whose output is consistent with OF
- timeName
- Name of the current time as a string. Allows the construction of directory names
- outputTime
- Boolean that indicates whether this is a timestep where OpenFOAM will write output
The missing operators from the fvc
-namespace have been added to
the Field-parser. These are
d2dt2
- for all volumeFields
flux
- for all volumFields. Needs a surfaceField as a first argument
meshPhi
- for volume-vector-fields. Optional with a scalar-field that acts as the density as the first argument. Only works in the context of a solver with a dynamic mesh and hasn’t been tested yet
The only missing operators from the fvc
-namespace are
volumeIntegrate=/=domainIntegrate
. These have been omitted as
they are trivial to implement using other functions
Thanks to patches supplied by Bruno Santos (see http://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=105) compilation of the libraries is now possible in parallel
Releases up to now got a version number. Utilities now report the version number. This should make it easier to find out whether problems are due to an old version
Still looking for a way to do that for the libraries (so that they will report it if dynamically loaded)
make dpkg
now genrates also a valid package if the current
OpenFOAM-installation is not installed using the dpkg
.
For parallel runs the content of the caseDir
-variable changed
and a few variables have been added
- caseDir
- in parallel runs now points to the
FOAM_CASE
instead of the processor subdirectory - systemDir
- points to the global
system
-directory - constantDir
- points to the global
constant
-directory - procDir
- in parallel runs points to the processor-subdirectory of the current CPU
- meshDir
- The mesh data (of the current processor in parallel runs)
- timeDir
- Directory where data would be written to at the current time (processor dependent)
In parallel runs the user must set the isParallelized
to true
if the parallelMasterOnly
is set to false
.
With that he indicates that in his opinion the Python-code has no bad side-effects in parallel runs and that he doesn’t blame swak4Foam if anyting bad happens
As reported in
https://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=119
due to a change the way the PISO-loop is treated the
interFoamWithSources
and interFoamWithFixed
don’t compile
with 2.1 anymore.
To avoid #ifdef
in the solver sources there is now a separate
set of sources (labeled pre2.1
) for older versions. The regular
sources work with 2.1 (and hopefully the following)
Function-objects only work with the
while(runTime.loop())
-construct in 2.1. The utility now uses
this.
Bug reported: http://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=124
An expression like 2*U
did not work for the field U
. Reason
was that the registry already held an object called U
(the
dictionary representation of the field) and therefor refused to
load/register another U
.
Has been fixed by de-registering the dictionary U
immediately
after loading.
The gradient for a vector field (result: a tensor field) was not calculated. It is now part of the grammar
tr
, inv
and det
were not working for some tensort types in
1.6-ext. The parser now fails if such a combination is
used. Works OK for other OF-versions
Also introduced a workaround for certain operators not being properly defined for pointFields (by using the internal fields)
These symbols could not be used as field names because they were used for the components of vectors and tensors
Now these names are only used if the .
-operator asks for a
component. This is implemented for these parsers
- FieldValues
- PatchValues
- SubsetValues (all Zones, sets and samples)
- finiteArea-Parsers: faPatch and faField
All parsers except the field-parser were missing the access to tensor components in the grammar
As mentioned in
https://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=130
it was not possible to construct a point-vector field using
vector(toPoint(1),toPoint(1),toPoint(1))
. Same for tensors
The error message in funkySetFields
that was issued when a
field is supposed to be created was not very helpful (something
about the field currently being an IOobject
)
This function was reported missing on the message board
The composed objects got their size from the current parser, not the components. This resulted in a segmentation-fault for pointFields
Preprocessor symbol linux
unknown. Replaced with __linux__
Now handles bad or non-existent filenames for dictionaries to track
Fix provided by Martin Beaudoin
This version is needed for the reentrant parsers. 2.5.33
may
work but is untested. Version 2.5.4
which is on some old
systems definitely does not work
Version 2.3 compiles but there is an offset-problem with the locations that breaks the Plugin-functionality
Mac-users will have to install bison
from another source (for
instance MacPorts
)
On Ubuntu /bin/sh
is something else and the scripts fail.
Hardcode to /bin/bash
This script (which was removed long ago) was still referenced in
the Makefile
.
grad
and other operators from fvc
added dimensions to values
that were supposed to be dimensionless. This has been fixed
Due to a typo the constructed condition field was too short for surface-fields (too long for volume-fields, but that didn’t matter)
The field-driver created patch fields there as calcuated
when
zeroGradient
would have been more appropriate
A SortableList
was used which meant that the vector with the
flip values was not in the correct order
This problem was due to a non-special treatment of faces on the
boundary. Fixed (for faceZone
as well).
Also boundary faces are now honored in expressionToFace
if the
expression is a surface-field (for the volume-field logic
boundary faces will never work)
The reason was that during construction refGradient
, refValue
etc were not read correctly (if present).
This is now fixed in groovyBC
and the other BCs (groovyBC
for
pointFields and groovyBCDirection
)
The Lexer correctly identified the variable but the getField
method did not know how to get it.
Fixed
If no condition was evaluated the utility generated a pseudo-field of the wrong length
For some operations in the Field
-driver the
calculated
-patches had the value
The FaField
-driver did no fixing of the calculated
-patches at
all.
This is fixed
Reported in http://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=150
Added the sqr
at the right place to the grammars. Also some
other missing tensor operations (dev
and symm
).
Patch fields were not copied any no correctBoundaryField
was
called for technical reasons.
Fix: values copied by hand
Introduced a preprocessor symbol that allows using sortedToc on newer versions
This was due to a strange () (still don’t know what happened there)
The strings of parsed IDs were not properly deleted. Funnily this was done correctly in the Patch and the Subset-driver. Also for timelines-
Also fixed a leak with the labels of plugin-functions that was present with all drivers
Reported by Oliver Krueger that on systems where /bin/sh
is not
a bash
anymore (newer Ubuntu and SuSE) the sourcing of
theFiles.sh
doesn’t work anymore.
Fixed and moved all the files to the maintainanceScripts
-folder
Added. Diag had to be reprogrammed as it is not implemented for fields (probably for performance reasons).
Also some tensor operators were missing (probably lost during copy/paste)
Reported in https://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=153
Fixed by removing all file pointers if the number of patches changes
Spaces in the list of variables made the reading fail because words can’t contain spaces. For instance
"var =T*2;"
Now all the spaces are removed before assigning to variables. This will also remove spaces on the “inside” thus making
"v ar =T*2;"
the same as the above expression. But it is unlikely that the call will be used in this way
These valid div
-operations were missing from the grammar:
- Divergence of a volume-tensor (all three kinds) producing a vector
- Divergence of a surface-tensor (all three kinds) producing a volume-tensor
Fields created by that function object were written with the value from the timestep before because the regular write occurs before the execution of the function objects.
Fixed
Now an initial value is required (instead of the default empty string which caused parser failure)
Reason is that during the calculation of the variables dimensions are checked.
Now the functionObject switches the checking off. But a more general solution is desirable
The functionObject does not write (and calculate) the field at the last timestep.
Fixed with an one-liner
Reason was an uninitialized valueFraction
which sometimes has
values that cause a floating point exception. Fixed
Because size()
was equal to the expected size on some
processors. Not on all. Now the branch is taken if the size is
equal on all processors
Fields were not written after the boundary condition was updated. Now they are
The topology operators expressionToCell
, expressionToFace
and
expressionToPoint
now support variables
and the other
supporting keywords if being constructed with a dictionary (for
instance from the topoSet
-utility)
Usually the manipulated version of the fields is not written as
the manipulation happens after writing. The option
writeManipulated
enforces writing.
Writing is not the default behavior to avoid side-effects
The function onPatch(name)
returns a surface-field that is name
.
The function internalFace()
is
Now the second argument to the pow
-function can be a
non-constant
The expression A.T()
transposes the tensor A
(for symmetrical
and spherical tensors it leaves them untouched)
If no field I
is defined then this is used as the unit-tensor
The unary operator *
calculates for tensors and symmetrical
tensors the hodge dual
The optional entry useFunctionObjects
switches on the execution
of function objects during the calculation
The optional entry addDummyPhi
creates a phi
-field
The dimensions
-entry is now read at the same time the variables
are read (this should work for all programs/functionObjects where
the parser is not constructed using a dictionary but the
dictionary is later searched for the variables
-entry)
This allows easy extension of the functionality of swak4Foam
without modifying the grammar files.
The way it works is that new functions are added to a runtime-selection table. If the grammar can not resolve a symbol as a built-in function or a field (but only then) it looks up the name in this table and evaluates the function. Parameters are parsed separately and can be:
- primitive data types
- integer, float, string and word
- swak-expression
- an expression parsed by one of the swak-parsers. The type of this expression does not necessarily have to be the same as the one of the ‘main’ expression.
The first time a plugin function is searched swak4Foam
prints a
list of all the available functions of this type. Information
included is the return type and the types of the parameters
(these include the parser used, the expected type and a parameter
name).
Libraries with plugin-functions are added via the libs
-entry in
the system/controlDict
A number of plugin-libraries are already included covering these topics:
- Evaluation of functions of the turbulence, transport or thermo model
- Different random number distributions
- Functions to “project”
sampledSets
andsampledSurfaces
onto a volume-field - Execute explicit discretization functions (like
grad
) but select the used scheme in the function instead of using the value fromfvSchemes
- Calculations of the mesh quality (same way
checkMesh
does) and return as fields - Do calculations locally on a cell (like the maximum on its faces)
- Get the source fields and other properties from lagrangian clouds based on the basic intermediate cloud classes (Kinematic, Thermo, Reacting, ReactingMultiphase)
It has been tried to make the names unique instead of short. Usually function names from one library are prefixed with the same short string.
The new dynamicFunctionObjectListProxy
in the
simpleFunctionObjects
can generate a functionObjectList
from
a string and execute them during the run like regular
function-objects.
The string is provided by a special class (the so called
dictionaryProvider
). Current implementations for the provider are:
- fromFileDictionaryProvider
- reads the text from a dictionary file
- stdoutFromCommandProvider
- executes a program and takes the standard output as the dictionary text
- stdoutFromPythonScriptProvider
- executes a python-script and takes the stdout as the dictionary text
The string must be in the format o a regular OpenFOAM-dictionary
with an entry functions
from which the functionObjects are
generated
This FO in the simpleFunctionObjects
reads a number of fields
and updates their boundary conditions at every timestep.
Main purpose is to let groovyBC
do calculations and use the
results for post-processing purposes
Does not support surface-fields as these don’t have a
correctBoundaryConditions
-method.
Example of the usage in the angledDuctImplicit
-case (the
results are of limited value because of the temperature boundary
condition)
Three source terms were added. These source terms are in the
swakSourceFields
-library and can be used with solvers that use
the sourcesProperties
-dictionary. The sources are
- SwakSetValue
- sets values according to a mask or the
mechanism provided by
basicSource
- SwakExplicitSource
- Uses the calculated source term on the right hand side of the equation
- SwakImplicitSource
- Uses a calculated scalar-field to add an implicit source term (source is without the actual field)
These fields are only implemented in the 2.x-version of swak
because the interface of basicSource
is very different in 1.7
and a backport was unnecessary
simpleFunctionObjects
now has a function object
writeAndEndFieldRange
that stops a run (and writes the last
time) if a field is outside a specified range.
A similar function object writeAndEndSwakExpression
is in the
simpleSwakFunctionObjects
that stops if a swak-expression
evaluates to true. writeAndEndPython
does the same in
pythonIntegration
.
Note: after the run is written one more timestep is calculated (this seems to be due to the fact that FOs are calculated at the start of a timestep). Also there are issues if the next timestep is a scheduled write-time (this only seem to be an issue with 1.7.x. It all works fine on 2.1.x)
New function objects in the simpleFunctionObjects
allow the
loading of such models for solvers/utilities that don’t have such
models but where some functionObject (for instance) needs such a
model to be in memory
Added as part of the simpleFunctionObjects
some functionObjects
that create a cloud of particles and evolve them at every
timestep.
The appropriate fields needed by every cloud have to be present
(either supplied by the solver or via a functionObject
)
This function objects allows the manipulation of patch fields
like manipulateField
allows the manipulation of the internal
field. Only use if desperate
If a variable is declared in the delayedVariables
-list then its
behavior changes: when a value is assigned to that variable then
the value is not immediately used but after the time specified in
delay
. Values are stored at intervals storeInterval
and
interpolated linearly. If no stored data is available then the
value of the expression startupValue
is used.
This feature allows the modeling of boundary conditions that react with a delay to flow conditions
To satisfy the requirements of certain boundary conditions
funkySetFields
now allows the preloading of fields. This is
only available in dictionary mode with the preloadFields
-entry
(for each entry in the expressions
-list separately)
The environment variable SWAK4FOAM_SRC
is needed for the
swakCoded
-functionObject. The Allwmake
-script now checks
whether this variable exists and prints a message with the
correct value if it doesn’t. It also checks whether the value is
correct and warns if it isn’t
The links to mybison
and myflex
are missing when the sources
are downloaded as a tarball. The Allwmake
-script now creates
these links if they are missing
Sources of the parsers have been completely reformatted to make them more readable and maintainable
Make the directory a little bit cleaner
To avoid clashes with other similar efforts (not that I know of
any) the library libpythonIntegration.so
has been renamed to
libswakPythonIntegration.so
.
Usually only the libs
-entry in the controlDict has to be
changed (if the library is used at all). Names of the function
objects stay the same
Now the outputControl
-entry is honored. If set wrong the field
is no longer calculated/manipulated at every time-step
Branch only compiled on 2.1, but not on 2.0 due to changes in the OpenFOAM-API
Fix provided by Bruno Santos
If no refValue
is given during construction then a value of
Fixed by using the value
as the refValue
if no refValue
is
specified
The error message occured much later when a tmp
tried to copy a
NULL
-pointer and was not obvious at all for the general user. Fixed
1.6-ext does not consider the product of two symmetrical tensors to be symmetrical. Fixed
Change in the interface of the ExpressionResult
-class
broke the access of global variables from a
Python-functionObject. Fixed
This didn’t influence the compilation (as there is already a current version file there) but confused people.
Face and point fields did not propagate the information correctly and were treated as non-uniform volume fields of the wrong size. This should now be fixed
The reason was that the patches of the divisor had a value of
zero. This has been fixed by only dividing the
internalFields()
. Same for pointFields
.
This kind of patch was not identified as something that could have the value fixed <<<<<<< variant A
The definition of the operator lessOp
clashed with another
definition. Renamed.
Fix provided by Bruno Santos
expressionFields
were calculated at every time-step, even if
the computational cost was high. Now if outputControl
is
outputTime
the field is only calculated if it is going to be
written
Seems like this one was overlooked because gcc
is more
tolerant towards stupidity.
Reported by Edo Frederix
On the slides the case files were promised
It is now possible for expression on internalFields
to access
fields from different cases. These fields are always read from
disk when being accessed for the first time and stay cached in
memory until the time is changed. The data is interpolated to the
current mesh with the meshToMesh
-class (which is the workhorse
of the mapFields
-utility)
The meshes are stored in a repository and are accessed via a
name. If for instance the mesh is known under the name
otherMesh
then in an expression the term otherMesh(T)
is the
field T
from that other mesh at the specified time interpolated
to the current mesh.
Certain function objects and parser instances allow specifying
foreign meshes in a subdictionary foreignMeshes
.
This is the long asked for feature to “get non-uniform values
from other patches”. It only works if the patches are specified
as mapped
(or directMapped
for 1.x). Therefor a patch can
only access one other patch with this.
On a mapped patch mapped(T)
gets field T
from whatever this
patch maps from (other patch, cells, faces). mappedInternal(T)
gets the values from the internal cells on the other patch (this
only works for patches).
On a mapped patch an external variable expression for patches now
changes its meaning: if other
is the patch that the current
patch maps from (and only then) then var{patch'other}=expr
evaluates expr
on the other patch and then maps the values to
the current patch (var
may be non-uniform). In all other
circumstances var
will get a uniform value which is derived
from whatever expr
evaluates to.
To allow non-uniform offsets
in the specification of mapped
patches in polyMesh/boundary
a utility
calcNonUniformOffsetsForMapped
was developed.
The framework for function objects that manipulate the runTime
were added. The concrete implementations are
- setDeltaTByTimeline
- set the timestep from a data file
- setDeltaTWithPython
- set the timestep by evaluating a Python-snipplet that should return a floating point number
- setEndTimeWithPython
- set the end time from the evaluation of a Python-snipplet
The library libswakChemistryModelFunctionPlugin
adds the
possibility to calculate properties of the chemistry like
reaction rates, chemical timescale and released energy.
Currently only implemented for psiChemistryModel
If there is no chemistry model in memory it will be loaded and the reaction rates are calculated.
There is a function psiChem_updateChemistry
that forces the
chemistry to be recalculated with a specified timestep. For
technical reasons this returns a scalar field with the value
psiChem_updateChemistry(0.0001)+psiChem_RR(CH4)
calculates the
reaction rate assuming that the timestep is
Two additional functions that sum up all the reaction rates (this
should be
The library libswakRadiationModelFunctionPlugin
adds the
possibility to calculate properties of the radiation like
parts of the source terms Rp
and Ru
and the current
radiation source
If there is no radiation model in memory it will be loaded and
the reaction rates are calculated. Assumes the presence of a
temperature field called T
.
If the numpy
-library is found then global variables which are
fields are being transformed to numpy
-arrays. These arrays can
be accessed with the usual numpy
-array access like a[i,j]
or
a[i,:]
. Global variables are made accessible by
reference. This means that writing a value changes the global
variable. Setting the whole variable has to be done by slicing
a[:]=3
(a=3
removes it from the workspace). Vectors and
tensors are two-dimensional arrays. They have
convenience-attributes that return the whole vector of a
component (like a.x
for vectors or a.xx
for tensors). To
overwrite these they have to be sliced: a.x[:]=0
(a.x=0
only
changes the attribute)
If a variable that is going to a global namespace is a
numpy
-array then it is translated by the following rules:
vectors are transformed to scalarField
. Arrays with 3 columns
to vectorField
, 9 columns to tensorField
and 6 columns to
symmTensorField
. Different column-numbers produce errors
If this is set then this Python-code is executed every time a time-step was written to disk
Python-integration now has two conventience-functions that return a filename with the full path and create the directories if necessary. The file is not created (that is the responsibility of the Python-code).
The functions are (name
is the name of the function object)
- dataFile(fname)
- creates a directory
<case>/<name>_data/<time>
. To be used for data that is written at times that differ from write-time - timeDataFile(fname)
- creates a directory
<case>/<time>/<name>_data
. Should only be used for data that is written only at write-time
A command lione switch -noDimensionChecking
is added that
allows switching off the checking of dimensions if this makes
expressions fail
If another case (with time and region) is specified via command
line options (no dictionary) then in the expressions the other
mesh can be accessed under the name other
Main application for this is comparing to other cases (but also comparing different timesteps of the same case with each other).
Used time is either fixed or set to the currently used (this can be selected via the command line)
Each expression can specify foreign meshes with a
foreignMeshes
-subdict
There are two new function objects:
- addForeignMeshes
- this allows specifying new foreign
meshes. These can be used in subsequent function-objects or
other swak-expressions on
internalFields
- foreignMeshesFollowTime
- this allows specifying a list of meshes whose time is set to the current time of the running case
This helps debugging timestepping-strategies
A new possible entry for the accumulations
calculates an
average that is weighted by a facetor that depends on the entity:
- cell volume if applicable
- face area for surfaces etc
-
$1$ if there is no appropriate weight (usually values defined on points). The result is equivalent toaverage
.
The title says it all. Should give the user additional feedback about what is happening
This boundary allows specifying the partial slip fraction of the
regular partialSlip
-BC with an expression.
This is sometimes necessary to allow calculations with fields where the boundary conditions have a lot of dependencies (turbulence model, other mesh etc)
The option -additionalRegions
allows selecting additional mesh
regions for boundary conditions that require it (usually used
together with -preloadFields
).
For the other case there is an additional option
-otherAdditionalRegions
.
This option allows specifying additional field names to be preloaded in command line mode. If multiple mesh regions are specified (including another mesh)it will try to preload the field there too
Support for tensor-types has been added
For boundary conditions that require other fields these can be loaded into memory
The utility now allows the selection of timesteps. In that case it acts fundamentally different: instead of doing a timeloop it jumps to those times, calculates the boundary conditions and writes. The purpose of this mode is generating boundary fields for postprocessing.
As the majority of installation problems were actually problems
with the compilation of the library swak4FoamParsers
and as
this library is central for all other things in swak4Foam
the
compilation terminates if this library is not built
This new header includes information about the
swak4Foam
-version, the OpenFOAM
-version and macros for
workarounds that depend on the OpenFOAM-version
This forces the entries to be checked while being read. Allowing more consistent treatment
This script allows compiling additional versions of
swakPythonIntegration
for cases where the version on the
development machine is different from the version on the
simulation machine (see installation chapter)
Changes without consequences for the user
The valid characters for an identifier were the same as in word
(was string
before)
The list of contributors to each file have been added (mostly by script with the information from the repository)
This abomination from the early days of funkySetFields
has been
cleaned
Changes to the documentation
A first version of a reference manual is added. Only the first part about expressions and parameters is written.
This is the first version to compile with OpenFOAM 2.2
Due to changes in OpenFOAM it requires several #ifdef
(something
that is usually avoided in the OpenFOAM-world) and other
prepocessor definitions)
Due to incompatibilities between OpenFOAM 2.2 and previous versions there are compatibility headers included from the rest of swak4Foam.
Theoretically both libraries can be easily made independent again.
The last release (0.2.2) did not compile on 1.6-ext
. This is
fixed
Due to a stupid .hgignore
the 0.orig
-directories were
missing. Nobody complained though
This has been fixed
With the options autoWriteSurface
and autoWriteSets
sampled
surfaces and sets are automatically written at each write
time. With writeSurfaceOnConstruction
and
writeSetOnConstruction
both are written when they are
created. A format has to be specified. No values are written.
These function and some other minor ones (sph
, dev2
,
twoSymm
) are now supported by the parsers
The component operators .x
, .y
and .z
now extract the rows
from a tensor
As this situation (like a variable named p
for the position
that shadows the pressure field p
) leads to weird errors a
warning is given. The warning can be switched of with the option
variableNameIdenticalToField
.
According to the convention introduced in OpenFOAM 2.2 now the
data directories generated by functionObjects based on
simpleFunctionObjects
(that is almost all) and
swakPythonIntegration
(if the Python-code uses the
dataFile
-function) are generated as sub-directories of
postProcessing
in the case directory.
Scripts that rely on the location of these files will have to be adapted
This is due to a fix that now allows reading/writing these in binary mode. Only occurs if reading old data that either
- uses a delayed variable
- has global variables written in timesteps
This may break them for previous versions of OpenFOAM
The C-files generated by bison
become very big and some
compilers need quite long when aggressive optimization is
used. An additional environment variable
SWAK_COMPILE_GRAMMAR_OPTION
allows the specification of
additional compiler switches (like -O1
) that will appear
after the regular switches and should alter the behavior of
the compiler. Set in swakConfiguration
if you want to set this
permanently
Some distributions don’t use good old bash
as the default
shell. This breaks some scripts in subtle and not so subtle ways
To filter bug-reports with outdated versions
Changes without consequences for the user
Methods that look for fields now use the appropriate data type
There were template specializations for pTraits
in
ExpressionResult.C
that had to be moved to ExpressionResult.H
to allow compilation on these non-=gcc=-compilers
Even if the condition evaluates to false
the function objects
in the list are executed. This makes the run fail if the purpose
of the condition was to guard from such a situation. Fixed
This was fixed by writing the fields properly with
writeValue
. This may introduce a little incompatibility when
reading files written by old versions
These fields were registered with the mesh which might have disturbed similar named real fields. Also did the fields generated for variables get registered
Missing initial conditions made this case a bit pointless
This was due to the boundaries being set to 0. Fixed. Also for
the dist()
function
The library simpleSearchableSurfaces
adds more searchable
surfaces to be used in snappyHexMesh
. Types of surfaces in
that library are
- some objects that duplicate existing surfaces and are only there for historical reasons (except the cylinder which distinguishes between different sides). Others wrap existing surfaces and expose the different sides
- wrappers for other surfaces that do coordinate transformations with it: rotation, translation, scaling
- wrappers that take two surfaces and do boolean operations with them: union, intersection, difference, exclusive difference
- Some wrappers that manipulate the regions of a surface: rename them, collect them into one region
This type is used to collect multiple values. If it is assigned a value then the uniform value of the right hand side is appended to the variable. Useful for collecting multiple values for output.
Variant StoredStackExpresionResult
keeps the values between
timesteps and allows the collection of timeline data
Dumps the value of a global variable into a line of a file
Removes a global variable (mainly used to preserve memory)
This dictionary allows the specification of alias names and
their real names. If an alias name is found in an expression
then it is replaced by the real name when looking for
fields. The application for this is that OpenFOAM allows
characters in field names that are not valid in swak-names and
would break the grammar if they were (for instance -
or
:
). By setting an alias such fields can still be accessed.
The function object listRegisteredObjects
in the
simpleFunctionObjects
lists all the objects currently
registered with the mesh. Mainly used for debugging (“Which
fields are currently available?”)
The new functionObject executeIfParallelSerial
allows
specifying if a list of function objects should only be run if
the simulation is running in serial or parallel.
There are now four function objects that calculate distributions
of fields. Distributions are calculated based on the
Distribution
-class that is part of OpenFOAM starting from
version 2.0 and uses a weighting for added values. There are two
kinds of output
- a timeline with the key characteristics of the distribution
- directories with the distributions at specific times. These are written “raw” and accumulated
For tensors and vectors these are output separately for every component. These outputs can be switched on and off separately. The user has to specify the bin-width for the classification. If the bin-width is too small and the distribution becomes too small it is scaled down.
The two function-objects in the simpleFunctionObjects
are:
- fieldDistribution
- distribution of field values weighted by the cell volume
- patchFieldDistribution
- distribution of a field on a number of patches weighted by the face area
In swakSimpleFunctionObjects
the two functionObjects are:
- swakExpressionDistribution
- distribution of an
expression
on some entity. The user also has to specify and expressionweight
with the weight of each value and a logical expressionmask
. Values are only used ifmask
istrue
at the place - patchExpressionDistribution
- distribution of
expression
on a number of patches. As the weight the face-area is used
This allows other variable types like stored variables to be inserted there. They are also now saved for restarting
All classes using the python interpreter now have a variable
endTime
with the current end-time value
If one of the functionObjects for time-manipulation set the end-time and it is reached and this is no time for output a complete output of the fields is forced
This includes the patchExpression
-functionObject. The supplied
list is now interpreted as a list of regular expressions and all
patches that match are included and processed
An optional parameter outputControlMode
now allows control on
when the function object will be executed. Possible values are:
- timestep
- Every
outputInterval
timesteps the object will be executed. This is the default behaviour with an interval $1$ - deltaT
- Approximately every
outputDeltaT
times it will be executed. The nearest possible timestep is used - outputTime
- Executed whenever a regular output is scheduled
Two enhancements
- the name of the independent variable no can be specified. This variable holds the value that is passed to the data entry as a uniform value
- data entry can now be integrated. This allows using it for instance for the injection rate in lagrangian models