README
for swak4Foam
- Version for OpenFOAM 2.x
Description
A collection of libraries and tools that let the user handle OpenFOAM-data based on expressions
About this document
Scope
This file gives an overview of swak4Foam
and a history of the
features. It is not a canonical documentation.
Technical
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.
The Markdown-variant README.md
is only there to be displayed in a
human-readable form by the web-interface to mercurial
at
sourceforge.net
. It is generated from REAME
and only updated
during releases. Don’t edit it.
Contributors etc
Original Author
Bernhard Gschaider (bgschaid@hfd-research.com)
Current Maintainer
Bernhard Gschaider (bgschaid@hfd-research.com)
Contributors
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
- Generation of dependencies for files that need Bison generated tab.hh files. This allows not having race conditions during parallel compilation
- Hrvoje Jasak
- Fixes to compile on Intel and CLang
- E.David Huckaby
- Add the writing of particles to
writeFieldsOften
- Alexey Matveichev
-
- release generation script.
- Automatic
swakConfiguration
- Mark Olesen
-
- port to OpenFOAM+ since v1612
- improvements to scripts
- Philippose Rajan
-
- Bugfix for segmentation faults in parallel
- Matti Rauter
-
- Spell-checking the compilation scripts
- Danial Khazaei
-
- Fixed problem with 64 bit labels
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. EMail is the
latest under which this author submitted):
- 2006-2020 Bernhard F.W. Gschaider <bgschaid@hfd-research.com>
- 2008 Hannes Kroeger (hannes@kroegeronline.net)
- 2008-2009, 2012 Martin Beaudoin, Hydro-Quebec (beaudoin.martin@ireq.ca)
- 2010 Marianne Mataln <mmataln@ice-sf.at>
- 2010 Oliver Borm (oli.borm@web.de)
- 2011 Alexey Petrov <alexey.petrov.nnov@gmail.com>
- 2011 Petr Vita <petr.vita@unileoben.ac.at>
- 2012-2016 Bruno Santos <wyldckat@gmail.com>
- 2013 Georg Reiss <georg.reiss@ice-sf.at>
- 2014 Hrvoje Jasak <h.jasak@wikki.co.uk>
- 2014 David Huckaby <e.david.huckaby@netl.doe.gov>
- 2015 Domink Christ <d.christ@wikki.co.uk>
- 2015 Alexey Matveichev <alexey.matveichev@gmail.com>
- 2016-2019 Mark Olesen <Mark.Olesen@esi-group.com>
- 2019 Danial Khazaei <shadowfax@shell.sf.net>
Documentation
See: http://openfoamwiki.net/index.php/contrib/swak4Foam
Installation/Compilation
If everything goes well then
./AllwmakeAll
should compile the essential requirements before compiling
swak4Foam
itself (remember: there is an if in that sentence)
Requirements
- Version 2.0 or higher of OpenFOAM and version 3.0 or higher of
Foam.
The oldest version that this is release has been tested with is OpenFOAM 2.3
To see which versions this release has been tested with see
Documentation/examplesCompatibilityMatrix.org
- the compiler generators
bison
andflex
- bison
swak4Foam
is known to work withbison
version 3.3 and higher.- 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
or too high versions compile special version. This can be easily
done by calling
./maintainanceScripts/compileRequirements.sh
in the directory of the sources. This will download a fitting
bison
version, compile it and install it in such a way that it is
only used during the compilation of swak4Foam
.
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
Scripting languages
If some scripting language integration should be used then the
appropriate development packages for that language must be
installed (something like python-devel
) for Python. This differs
on the various platforms. The settings for your machine read from
the file swakConfiguation
if it is present. The file
swakConfiguation.automatic
tries to guess these settings so
either copy it with
cp swakConfiguation.automatic swakConfiguation
and modify it or link it
ln -s swakConfiguation.automatic swakConfiguation
but be aware that if modifying it the original is modified.
Because of its small footprint and to avoid problems on
distributions where it is outdated Lua
is automatically compiled
by the maintainanceScripts/compileRequirements
script and
swakConfiguration.automatic
uses this version if found. It may
be necessary to install the development package of readline
for
this
The script will also install luarocks
(the Lua package manager)
and using that luaprompt
. The luaprompt
-library will be used
for interactive interactions with the Lua-integration (making it
more comfortable)
Building
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)
Additional configuration
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. There is also a file
swakConfiguration.automatic
that tries to automatically
determine the location of Python. It does not work on all systems
and therefor is not enabled by default). If that file is not
present these unconfigured features will not be compiled.
Environment variables that can be set in this file are:
- SWAK_PYTHON2_INCLUDE
- Path to the
Python.h
file of the usedpython
-installation - SWAK_PYTHON2_LINK
- Options to link the
python
-library to the library for thepython
-integration - SWAK_PYTHON3_INCLUDE
- Path to the
Python.h
file of the usedpython3
-installation - SWAK_PYTHON3_LINK
- Options to link the
python3
-library to the library for thepython3
-integration - SWAK_LUA_INCLUDE
- Path to the header files of the used
Lua
-installation - SWAK_LUA_LINK
- Options to link the
Lua
-library to the library for theLua
-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) - SWAK_COMPILE_LEXER_OPTION
- Additional compiler switches for
files generated by
flex
. For some compilers (Intel) aggressive optimization when compiling these files may cause uninitialized memory and crashes. This variable can be used to switch off the optimization (usually this fixes the problems) - SWAK_TEST_RACE_CONDITIONS
- Meant to be used only by developers, for performing a verification on whether race conditions occur during parallel compilation, regarding the grammar parsers.
Possible compilation failure with old 2.0.x-versions
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)
Special versions of the python integration
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_PYTHON2_INCLUDE
SWAK_PYTHON2_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.
Global installation
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
Packaging
Debian
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
Contents
Libraries
Collection of Libraries
swak4FoamParsers
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
simpleFunctionObjects
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.
groovyBC
Implements the infamous groovyBC
. A boundary condition that
allows arbitrary expressions in the field-file
swakFunctionObjects
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
simpleSwakFunctionObjects
Function objects based on the simpleFunctionObjects
-library
(which is a prerequisite for compiling it).
Evaluate expressions and output the results
swakSourceFields
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)
swakFvOptions
Starting from OpenFOAM 2.2 this library has additional fvOptions
swakTopoSources
topoSources
for cellSet
and faceSet
. Can be used with the
cellSet
and faceSet
-utilities
swakFiniteArea
Implements parsers for the finiteArea
-stuff in 1.6-ext. Also
implements groovyBC
for areaField
and expressionField
and
other function objects
groovyStandardBCs
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.
simpleLagrangianFunctionObjects
Function objects that allow the easy addition of lagrangian
clouds to a case. No other libraries from swak4Foam
are needed
for this
simpleSearchableSurfaces
Additional searchableSurfaces
(for use in snappyHexMesh
)
which include boolean operations for other surfaces and
coordinate transformations
fluFunctionObjectDriver
Driver for functionObjects
that implemented entirely in Python
using the pythonFlu
-library
swakLagrangianParser
Parser for calculating expressions on clouds of lagrangian particles
swakStateMachine
Library with function objects and plugin functions to work with simple state machines
swakDynamicMesh
Library with classes that combine swak with dynamic meshes
functionPlugins
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)
- swakChemistryModelFunctionPlugin
- Functions that calculate chemistry properties (reaction rates etc)
- swakRadiationModelFunctionPlugin
- Functions that calculate properties of the radiation model
- swakMeshWaveFunctionPlugin
- Functions that use the
MeshWave
-algorithm to calculate grid-dependent properties like number of mesh layers
lagrangianCloudAdaptors-directory
Because of the templating all plugin-functions have to be reinstaniated for new particle classes. The libraries in this directory
- reimplement the functions from
swakLagrangianCloudSourcesFunctionPlugin
- the
CloudProxy
for thecloud
parser
for special particle classes. These are
- coalCloudAdaptor
- the library
libswakCoalCloudAdaptor
that handels theCoalParcel
-class
These libraries have to be included in the libs
-entry to
be able to handle these libraries
languageIntegration
Libraries that integrate various scripting languages with swak4Foam
swakGeneralLanguageIntegration
This library implements a common interface for the actual language integrations.
swakPythonIntegration
Embeds a Python 2
-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)
swakPython3Integration
Embeds a Python 3
-interpreter.
swakLuaIntegration
Embeds a Lua
-interpreter.
Utilities
funkySetFields
Utility that allows creation and manipulation of files with expressions
funkySetAreaFields
Utility like funkySetFields
for areaFields
(only works with
1.6-ext)
funkySetBoundaryField
Sets any field on a boundary to a non-uniform value based on an expression.
Acts without deeper understanding of the underlying boundary condition
replayTransientBC
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
funkyDoCalc
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
calcNonUniformOffsetsForMapped
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
fieldReport
Utility that quickly does some quantitative analysis (minimum, maximum, average etc ) on a field on the disc (internal field but also patches, sets, zones, …)
funkyPythonPostproc
This utility loads specified fields into memory, executes a list of user-specified function objects whose data is then passed to a python script which does the user-specified analysis.
funkySetLagrangianField
Utility to calculate fields for a lagrangian cloud (or setting it up from scratch)
writeBoundarySubfields
Utility to write fields with subfields from boundary conditions
like refValue
for post-processing
makeAxialMesh
A utility that converts a planar (pseudo-2d) grid to an axial-symmetric mesh (used to be a separate project but was moved here for maintenance)
Contributors of previous versions were
- David P. Schmidt
- E David Huckaby
- Dominik Christ (Porting to 1.5)
See: http://openfoamwiki.net/index.php/Contrib_MakeAxialMesh
Examples
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’
Note: Due to various changes in the case syntax between OpenFOAM
2.0 and 2.2 (for instance thermophysicalProperties
, wall
functions etc) not all of the examples work with all
OpenFOAM-installations “out of the box”. Slight adaptions may be
necessary
Some of the cases use the pyFoamPrepareCase.py
-utility of PyFoam
to set up the case for the current OpenFOAM-version
To run on multiple OpenFOAM-versions the cases sometimes have more entries in the dictionaries
Also have a look at Documentation/exampleCompatibilityMatrix.org
to see with which versions which cases should work.
Usually the cases have been derived from regular tutorial
cases. After their first implementation they were only adapted to
run in new OpenFOAM versions but improvements in the tutorials are
usually not ported. The reason is that these are just example
cases for swak4Foam
, not best practice examples for OpenFOAM
groovyBC
The old groovyBC
-Demos and newer cases that use groovyBC
pulsedPitzDaily
- Solver
- pisoFoam
- Also demonstrates
manipulateField
,expressionField
andclearField
from theswakFunctionObjects
.patchExpression
fromsimpleSwakFunctionObjects
.solveLaplacianPDE
andsolveTransportPDE
for solving equations,pythonIntegration
with calculations usingnumpy
- Preparation
pyFoamPrepareCase.py
wobbler
- Solver
- solidDisplacementFoam
circulatingSplash
- Solver
- interDyMFoam
- Preparation
pyFoamPrepareCase.py
movingConeDistorted
- Solver
- pimpleDyMFoam
- Also demonstrates
swakExpression
withsurface
. Due to a problem described below this currently doesn’t work
average-t-junction
- Solver
- pimpleFoam
- Mesh preparation
pyFoamPrepareCase.sh
delayed-t-junction
- Solver
- pimpleFoam
- Mesh preparation
pyFoamPrepareCase.sh
- Demonstrates
- Delayed variables to simulate an inflow that depends on the value of the outflow
multiRegionHeaterFeedback
- Solver
- chtMultiRegionFoam
- Mesh preparation
- Execute the script
prepare.sh
in that directory - Also demonstrated
patchExpression
andswakExpression
fromsimpleSwakFunctionObjects
.
fillingTheDam
- 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
sprinklingInlet
- Solver
- interFoam
- Description
- Winner of the
swak4Foam
-competition at the 6th OpenFOAM-Workshop (2011). By Peter Keller
potentialPitzDaily
- Solver
- potentialFoam
- Description
- Demonstrates the use of
groovyB
withpotentialFoam
(also a problem connected with that). Provided by Martin Backer
lookupDambreak
- Solver
- interFoam
- Preparation
- run
pyFoamPrepareCase.py
- Description
- Demonstrates the use of 2-dimensional lookup tables. For the initialization as well as the boundary condition
jumpChannel
- Solver
- icoFoam
- Preparation
- run
pyFoamPrepareCase.py
- Description
- Demonstrates
groovyBC
on cyclic patches and thegroovyBCJump
-condition
nonBreakingDam
- Solver
- interFoam
- Preparation
- run
pyFoamPrepareCase.py
- Description
- OpenFOAM macro-expansion inside of expression strings
FunkyDoCalc
Example dictionaries for funkyDoCalc
FunkySetFields
Example dictionary for funkySetFields
FunkySetBoundaryFields
Example dictionary for funkySetBoundaryFields
. Sets nonsense
boundary conditions for the world famous damBreak
-case
ImmersedBC
Cases that demonstrate the immersed boundary conditions of foam-extend
InterFoamWithSources
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).
InterFoamWithFixed
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).
interFoamWithSources
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
mixingThing
Demonstration case for it.
- Preparation
- Run the script
prepare.sh
to prepare the case
FiniteArea
Demonstration of the finiteArea
-stuff that works with 1.6-ext
swakSurfactantFoam
Variation of surfactantFoam
that adds an expressionSource
planeTransport
Demonstration case
- Preparation
- Use
pyFoamPrepareCase.py
- Solver
surfactantFoam
(without source term) orswakSurfactantFoam
- Demonstrates
- FAM-specific
swakExpressions
andgroovyBC
(as well as theexpressionSource
)
FvOptions
Cases that demonstrate swakSourceFields
angleDuctWithSources
- Solver
- rhoPimpleFoam
- Mesh preparation
- Execute
pyFoamPrepareCase.py .
- Demonstrates
- Simple expression sources (adds a heat source to the solid)
heatExchangerSources
- Solver
- chtMultiRegionFoam
- Mesh preparation
- Execute
pyFoamPrepareCase.py .
- Demonstrates
- Getting the residuals of the matrix with the
matrixChangeBefore
andmatrixChangeAfter
fvOptions
other
Cases that don’t have a groovyBC
angledDuctImplicit
- Solver
- rhoPorousMRFSimpleFoam
- Mesh preparation
- Execute
pyFoamPrepareCase.py .
- 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
angledDuctImplicitTransient
- 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
capillaryRise
- Solver
- interFoam
- Case preparation
- run the
pyFoam
-utilitypyFoamPrepareCase.py
- Demonstrates
- Usage of a sampled surface to track the interface in a VOF-simulation
mixingDam
- Solver
- interFoam
- Case preparation
- run the supplied script
prepareCase.sh
- Demonstrates
- Emulate a “moving gravitation” by using the
manipulateField
-functionObject to recalculategh
andghf
counterFlowFlame2DInitialized
Demonstrates initializing a case with initial conditions that approximate the real flow.
- Solver
- reactingFoam
- Case preparation
- run
pyFoamPrepareCase.py
. Caution: this has to be done every time before running the case because the initialized fields are rewritten - Demonstrates
- Demonstrates setting calculated initial conditions with functionObjects
simpleBendedPipe
Demonstrates the use of funkyWarpMesh
and post-processing on
bended pip geometries
- Solver
- simpleFoam
- Case preparation
- Run
prepare.sh
topoSetDamBreak
Case to demonstrate various things about cell
and faceSet
- Solver
- interFoam
- Case preparation
- Run
pyFoamPrepareCase.py .
FromPresentations
Cases that were shown in some presentations
OSCFD_cleaningTank3D
- 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
OSCFD_cleaningTank2D
A 2D-variant of the above case
OFW8_sandPitOfCarcoon
- Solver
- twoPhaseEulerFoam
- Case preparation
- run the
prepareCase.sh
-script - Description
- Simulate a sand-monster from the StarWars-movie “Return of the Jedi”
- Demonstrates
- Use of
funkySetFields
,groovyBC
and functionObjects for lagrangian particles
OFW8_landspeedersInCanyon
- solver
- simpleFoam
- Case preparation
- run the
prepareCase.sh
-script - Description
- Simulates two landSpeeders (as seen in the StarWars-movie “A New Hope”)
- Demonstrates
- Advanced searchableSurfaces (for
snappyHexMesh
), functionObject for passive scalar, functionObject to calculate distributions
PythonIntegration
Demonstrate the integration of Python
. Mostly using PyFoam
but
also with pythonFlu
manipulatedPitzDaily
- 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)
findPointPitzDaily
- 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
bed2OfPisa
- 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
multiRegionHeaterBuildFunctionObjects
- Solver
- chtMultiRegionFoam
- Demonstrates
- Building the specification of function objects at run-time via a Python-script
slicedPitzDaily
- 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
CodeStream
Demonstrates working together with the coded
-stuff in OpenFOAM 2.0
solvePDE
Examples for the functionObjects
that can solve Partial
Differential equations
flangeWithPDE
- 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
pyFoamPrepareCase.py
pitzDailyWithPDE
- Solver
- scalarTransportFoam
- Demonstrates
- Solving additional transport equations
BasicSourceSubclasses
These examples test the source terms based on basicSource
. They
only work with OpenFOAM 2.x and all use the simpleFoam
-solver
pitzDailyWithSwirl
- Demonstrates
- Fixing the values of the velocity in a region
with
SwakSetValues
pitzDailyWithExplicitPoroPlug
- Demonstrates
- Implementing a simple porous plug by adding the
Darcy-term as a source term with
SwakExplicitSource
pitzDailyWithImplicitPoroPlug
- Demonstrates
- Same as
pitzDailyWithExplicitPoroPlug
but with an implicit source term withSwakImplicitSource
Lagrangian
Stuff that has to do with lagrangian particles
functionObjects
Tests for the functionObjects that create and evolve a cloud of
particles (library simpleLagrangianFunctionObjects
)
hotStream
- Solver
replayTransientBC
- Mesh preparation
pyFoamPrepareCase.py .
- Demonstrates
- 3 clouds (kinematic, reacting, solidParticle). Loading of a thermophysical model with a functionObject. Plugin functions for information about the clouds
angledDuctWithBalls
- Solver
- rhoPimpleFoam
- Demonstrates
- Thermo-cloud. Functions for lagrangian particles
icoFoamCavityWithParcel
- Solver
- icoFoam
- Demonstrates
- Simplest way to add particles to a case
parser
Testing the cloud
-parser for lagrangiant particles
parcelInBoxWithExpressions
- Solver
- reactingParcelFoam
- Demonstrates
- Adding evaluations on the cloud to a regular case
simplifiedSiwek
Variation of the tutorial case
- Solver
- coalChemistryFoam
- Demonstrates
- creating new clouds with
funkySetLagrangianField
and evaluations on clouds during the simulation - Mesh preparation
- run the
pyFoamPrepareCase.py .
script to set up the mesh and the fields
SimpleSurface
Examples for the use of the simpleSearchableSurfaces
-library.
twoMotorbikesAndAWall
- 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
littleVolcano
- Solver
- interFoam
- Case preparation
- Use
pyFoamPrepareCase.py
- Demonstrates
- Boolean operations on STL-files
chargedPlates
- Solver
- electrostaticFoam
- Case preparation
- Script
caseSetup.sh
is provided - Demonstrates
- Boolean operations with regular surfaces
Physics of the case not as expected (charge-distribution)
manipulateFvSolutionFvSchemes
Demonstrates the use of function objects that change the numerics during the run
pitzDailyTimeSwitched
The regular simpleFoam
-tutorial. Modified so that it switches
to higher relaxation factors during the run
pitzDailyStateMachineSwitched
simpleFoam
-tutorial. Uses state machines to change the
discretization periodically
StateMachine
Demonstrate the usage of state machines
stateCavity
The case is only an excuse for the state machines
- Running
replayTransientBC -allowFunctionObjects
- Case setup
pyFoamPrepareCase.py
DynamicMesh
Examples that demonstrate dynamic mesh applications
hecticInletACMI2D
Variation of a tutorial case where the oscillation has been replaced by an expression
- Solver
pimpleDyMFoam
- Case setup
pyFoamPrepareCase.py
- Demonstrates
- The
swakMotion
function forsolidBodyMotion
rotatingTank2D
- Solver
interDyMFoam
- Case setup
pyFoamPrepareCase.py
- Demonstrates
- The
swakMotion
function forsolidBodyMotion
switchedInletACMI2D
- Solver
pimpleDyMFoam
- Case setup
pyFoamPrepareCase.py
- Demonstrates
- The
groovyCyclicACMI
patch type
switchedTJunction
- Solver
compressibleInterDyMFoam
- Case setup
pyFoamPrepareCase
- Demonstrates
- The
groovyCyclicACMI
patch type. State machines.funkyWarpMesh
utility
runTimeControl
Demonstrating the run-time trigger
simpleSwakCar
Simple modification of the simpleCar
-case
- Solver
simpleFoam
- Case setup
pyFoamPrepareCase
- Demonstrates
- the run-time trigger with expressions.
MakeAxialMesh
Cases hee demonstrate the makeAxialMesh
-utility
axialCavity
The usual cavity
case with the axis outside the geometry
- Solver
icoFoam
- Case setup
pyFoamPrepareCase
axialPitzDaily
The usual pitzDaily
case with the top is an axis of rotation
- Solver
simpleFoam
- Case setup
pyFoamPrepareCase
Note: checkMesh
complains after the collapseEdges
-utility
was used and the case converges badly
tests
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
randomCavity
Testing of different seeds for the rand
-function. Also tests
the randFixed
-function
AMIPipe
Simple geometry for testing function objects with AMI. “Execute”
with replayTransientBC
, pimpleFoam
or pimpleDyMFoam
Features can be “switched off” with pyFoamPrepareCase.py
. What
can be switched on is a location dependent pressure jump on one
of the interfaces implemented with groovyBCJumpAMI
BugCases
These are cases provided by users to demonstrate bugs. Not maintained nor documented and may be removed at any time
maintainanceScripts
Undocumented scripts used for maintaining swak4Foam
. If you
don’t understand them, don’t use them
Documentation
Additional documentation. Most written in org-mode
Current contents:
- swak4FoamReference
- Reference manual of swak4Foam. Especially concepts like expression syntax and parameters
releaseTesting
Scripts and configuration to test for a release in a virtual
machine using vagrant
. Also to be used for packaging
distroPatches
Patches that have to be applied to releases to get swak4Foam to work with them. These are only needed to fix problems of the distributions
Development
Programs and libraries that are only used for testing/developing swak
Bug reporting and Development
Bug reports
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
Please always report the FOAM-version you use. As OpenFOAM-dev
is a moving target only bug-reports that add fixes are handled for this.
Things to do before reporting bug
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.
Development
Contributions to to swak4Foam
are most welcome. If you want to
contribute clone the Mercurial archive of the sources
hg clone http://hg.code.sf.net/p/openfoam-extend/swak4Foam
or use the Fork link at
https://sourceforge.net/p/openfoam-extend/swak4Foam/ci/develop/tree/
to create your own fork and clone that (there is also copy of the
repository at
https://bitbucket.org/bgschaid/swak4foam-temporary-replacement-for-original-repo-on
if you prefer that. But it does not receive pushes as often as the
Sourceforge repository. Please avoid any git
-clones of the
repository. They are unsupported and contributions through them
will take longer to be incorporated - if at all. The maintainer is
aware that git
is the Windows of the DVCS
-world: used because
it is the first thing people are exposed to. Not because of the
technical merit)
Change to the branch that you want to improve (usually develop
)
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
hotfix/WrongRandomFunction
or feature/HyperbolicFunctions
. For
details see Repository organization below). 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 you can either issue a Pull request (if you forked on SourceForge or BitBucket) or 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 develop
branch (do not
attempt to do this yourself) and subsequently into the
release. 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
.
Only if you got through Mercurial it can be ensured that your contribution is recognized (if you want to stay anonymous send patches).
Before submitting the branch please add a description to the
README
(have a look at the History
-part below). This will be
merged
Suggest reading
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
Repository organization
The organization of the repository is according to the Driessen
branching model described here
https://nvie.com/posts/a-successful-git-branching-model/ . To
enforce it this mercurial extension is recommended
https://bitbucket.org/yujiewu/hgflow/wiki/Home
For instance if a new feature foo
should be added then a command
hg flow feature start foo
creates a new branch feature/foo
from the develop branch which
later can be merged back with
hg flow feature finish
Special branches
Currently the main branches are:
- default
- The main branch. This is the brancht that the general public will receive. It compiles under OpenFOAM 2.0 and higher
- debianPackaging
- Branch for generating new Debian-packages of
swak4Foam
. If somebody wants to “inherit” this: contact the maintainer - develop
- Actual development branch
Maintaining feature and hotfix-branches
The repository comes with a .hgflow
-file that is set for the
hgflow
-extension found at
https://bitbucket.org/yujiewu/hgflow/wiki/Home (there are multiple
branches of this extension. This seems to be the most up-to date
and still under active development)
In the future this repository will try to stick to the model described in http://nvie.com/posts/a-successful-git-branching-model/
Copyright
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.
Known bugs
The following list is not complete. If the Artemis extension (see above) is installed then
hg ilist
gives a more up-to-date list
sampledSurfaces
Moving meshes and 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
Missing support for interpolation and point-Fields
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)
Caching of loaded fields not working
This is especially evident for the funkyDoCalc
-example
Possible enhancements of the code
Not really bugs, but stuff that bugs me
Pointers in the driver code
This is necessary because of bison
. Investigate possibilities to
replace these by tmp
and autoPtr
Possible memory loss
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)
&
of symmetric tensors
Non-treatment of the inner product 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
No point-vector construction for Subsets
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
No tab-completion for regular Python-shell and old IPython-versions
The tab-completion does not work except for up-to-date versions of
IPython. This seems to be a problem with the readline
-library
inside an embedded Python. Low priority
groovyBC
for commsType
blocking
Failure of If the commsType
is set to blocking
then the MPI-communications
of groovyBC
cause problems in MPI and a fatal error.
Currently the only workaround is to edit
$WM_PROJECT_DIR/etc/controlDict
so that a different commsType
is used (nonBlocking
or scheduled
)
sampledSurfaces
that change size on certain distros
Failure with Older Foam-versions had the problem that when the surface changes
the size then certain values (especially the mag
are not properly
recalculated).
This causes this bug: https://sourceforge.net/p/openfoam-extend/ticketsswak4foam/231/
The bug can not be fixed in swak4Foam
but has to be fixed in the
Foam-Distro
solverPerformanceToGlobalVariables
only works for scalar fields
Currently only the data from scalar fields can be correctly
parsed. If vector
-fields are specified the function object fails
Python2
and Python3
integration if Floating Point Exception is enabled
Failing On some platforms if floating point exceptions are enabled then
importing numpy
fails because it seems to use FPEs to detect
properties of the floating point implementation. This makes the
whole program fail.
Only known workaround is switching FPE-trapping off by
export FOAM_SIGFPE=false
History
2010-09-13 - version number : 0.1
First Release
2010-12-18 - version number : 0.1.1
New release Most important changes
sampledSurfaces
Parser for Now expressions for the field on a sampled surface can be
evaluated. All sampledSurfaces
offered by OpenFOAM now can be
used
variables
Multiline 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
Two maintainance-scripts were added
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
Parsers using ‘external variables’ are now run-time selectable
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)
2011-01-30 - version number : 0.1.2
Support for Finite Area-stuff
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
Bugfix for compiling in single precision
See https://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=49
nearDist
New function See https://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=44
2011-04-20 - version number : 0.1.3
New features and changes are (this list is not complete):
funkySetAreaField
New utility Like funkySetFields
for finiteArea. Also writes out a volume
field for easier post-processing
groovyBC
and groovified boundary conditions
Refactoring of Makes it easier to use the groovyBC
-machinery for other boundary
conditions. Two standard boundary conditions were
groovified. Others may follow
Easier deployment
If no simpleFunctionObjects
are present they can be downloaded
by a script.
Also scripts to handle global installations of swak4Foam
Force equations
A class to force equations to certain values according to expressions
funkyDoCalc
New utility 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
Debian packaging
Crude packaging for Debian
Lookup-tables
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)
Stored variables
Variables that store their values between time-steps. Applications are statistics or switches
Sampled sets
Sampled sets can now also be used as en entity on which calculation is possible.
2011-07-26 - version number : 0.1.4
Port to OpenFOAM 2.0
This is the first release that officially supports OpenFOAM 2.0
Also it is the first release that incorporates the
simpleFunctionObjects
-library
New features:
rand
and randNormal
Rewrite of - 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)
min
and max
Binary Take the bigger/smaller of two fields. Helps avoid ?:
-operations
funkySetAreaFields
Allow writing of only volume-fields in Application: If the results of the calculation are only needed in ParaView
Internal changes
- Use
autoPtr
for sets - Update sets that change in memory or on disc
Bug-fixes
funkySetAreaFields
did not check for the correct fields
Fixed by Petr Vita
surfaceProxy
uses the wrong geometric data
Avoid floating point exceptions with division of fields
Calculated boundaries were
Packaging
Update Debian packaging
- Packaging information for the currently used OF-version is
generated (allows a separate
swak
-package for every OF-version - Submission to launchpad added
Deployment scripts
Now install to FOAM_SITE_APPBIN/LIBBIN
2011-10-03 - version number : 0.1.5
New features
replayTransientBC
now supports multiple regions
Uses the usual -region
-option. Looks for a separate dictionary
in the system
-directory of that region
replayTransientBC
allows execution of functionObjects
This can be switched on using the allowFunctionObjects
-option
Python
-embedding
Allows the execution of Python-Code in a functionObject
This feature is still experimental and the organization of the libraries is subject to change
Global variables
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
Using OF 2.0 codeStreams
Adds a functionObject swakCoded
that extends the
coded
-functionObject to read and write global variables
groovyBCFixedValue
Simplified boundary condition 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)
Function objects to solve PDEs
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
Administrative and packaging
swak4Foam
into a distro
Inject 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
simpleFunctionObjects
Absorb As many parts of swak4Foam
depend on it the
simpleFunctionObjects
have now been absorbed into
swak4Foam
. They can still be compiled on their own
Bugfixes
Variables not working for parallel computations
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
2012-01-04 - version number : 0.1.6
Cases changed
circulatingSplash
Fixed according to a suggestion by Andreas Otto. Now runs again (used to crash some time-steps into the beginning)
Infrastructure
bison
-version
Check for correct 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
Supply a header with preprocessor-symbols about the used OF-version
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
Technical
Refactoring of the FieldDriver
- now can also produce surfaceFields
- full support of
tensor
,symmTensor
andsphericalTensor
Refactoring of the FaFieldDriver
- now can also produce edgeFields
No support for tensors yet
storedVariables
Writing of 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.
simpleFunctionObjects
now write vectors and tensors without brackets
Data files can now be written without brackets but each component on its own. The number of entries in the header is not adjusted
A default mesh for the drivers exists
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
)
New features
phi
in solveTransportPDE
General Due to the refactoring of the FieldDriver
now phi
can be
specified by a general expression (instead of ‘only’ a
field-name)
funkySetFields
now also writes surfaceFields
Can write surfaceVector
and surfaceScalar
-Fields. Condition
has to be consistent
surfaceField
-aware
Function objects now expressionField
and manipulateField
now can create or modify
surfaceFields
funkySetFields
and function objects support tensors
funkySetFields
and the function objects expressionField
and
manipulateField
now also work with the three tensor-types
expressionToFace
topoSet
Extension of the 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
addGlobalVariable
allows setting more than one value
If there is an entry globalVariables
then this dictionary is
used to set the variables
calculateGlobalVariables
Function object Calculates variables and then pushes them to a global namespace
phi
in replayTransientBC
Generate a dummy New option added that generates a phi
field with value inletOutlet
happy
Function object to dump expression results
The functionObject dumpSwakExpression
dumps the complete
results of a swakExpression to file at each timestep. This
produces huge files and is therefor not endorsed
funkySetFields
Additional options for Add the options allowFunctionObjects
and addDummyPhi
to
execute functionObjects and add a phi
-field (for fields that
require these)
groovcBCDirection
Boundary condition 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
groovyBCJump
Boundary condition Boundary condition that imposes a jump in the value on a cyclic
boundary condition pair (based on jumpCyclic
). Only works for
scalar values
simpleFunctionObjects
write CSV-files
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)
searchOnDisc
specified
Submeshes automatically read if If a submesh is not yet in memory and the option searchOnDisc
is set, the mesh is automatically read into memory and kept there
functionObjects
Conditional 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
functionObject
that reads gravitation
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 ….”)
finiteArea
PDE-functionObjects for Solve transport and laplacian equation
DataEntry
that uses swak-expressions
Subclass to 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
)
funkySetAreaField
now also writes edgeFields
Similar to the surfaceFields
in funkySetFields
Bug fixes
Compilation with Intel-Compiler possible
The Utilities
failed with the Intel-compiler. Compilation now
falls back to good old g++
Access to tensor-components not working
Because the tokens were not defined in the flex
-files getting
tensor components with tensor.xx
did not work. Fixed
Constants for surfaceFields not working
Because surfaceFields know no zeroGradient
the template
makeConstant
did not work
snGrad
does not work for patches if the file is on disc
Change so that the field gets temporarily loaded to calculate the
gradient on the patch. Same for internalField
and
neighbourField
potentialFoam
does not correctly use a groovyBC
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 conditions causes failure
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
Discontinued features
groovyFlowRateInletVelocity
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
2012-04-13 - version number : 0.2.0 Friday the 13th
New features
simpleFunctionObject
.outputs
Region name in 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)
ddt
and oldTime
Temporal operators 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.
groovcBCDirection
Boundary condition 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
groovyBCJump
Boundary condition 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
Function to return the position of minimum and maximum
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
pointFields
in the field-parsers
Support for 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
finiteArea
-field parser
Support for tensors in the 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
New convenience-variables for the Python-Integration
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
fvc
-namespace
Additional operators from the 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
Infrastructure
Full parallel compilation
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
Version numbers and version number reporting
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)
Packaging
Update of the Debian-Packaging
make dpkg
now genrates also a valid package if the current
OpenFOAM-installation is not installed using the dpkg
.
Changes in the behavior
Directory variables in Python-integration
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)
User must acknowledge parallelization in Python-integration
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
Bug fixes
interFoam
-based example solvers do not compile on 2.1
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)
-allowFunctionObjects
-option not working for replayTransientBC
Function-objects only work with the
while(runTime.loop())
-construct in 2.1. The utility now uses
this.
funkySetBoundaryField
Field itself can not be used in 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.
No gradient for vectors in FieldParser
The gradient for a vector field (result: a tensor field) was not calculated. It is now part of the grammar
Some operators for tensors not working in 1.6-ext
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)
x
, y
, z
and xy
etc not available as field names
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
Missing tensor components for point-Fields in some parsers
All parsers except the field-parser were missing the access to tensor components in the grammar
No vector construction possible for point-vectors (and tensors) in PatchField
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
funkySetFields
if the field is missing
Incomprehensible error message in 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
)
magSqr
in parsers
Missing This function was reported missing on the message board
Wrong size when composing vectors and tensors for point-fields
The composed objects got their size from the current parser, not the components. This resulted in a segmentation-fault for pointFields
icc
does not compile executeIfExecutableFitsFunctionObject
on Linux
Preprocessor symbol linux
unknown. Replaced with __linux__
trackDictionary
-functionObject
Enhancement to the Now handles bad or non-existent filenames for dictionaries to track
Fix provided by Martin Beaudoin
2012-10-18 - version number : 0.2.1
Requirements
flex 2.5.35
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
bison 2.4
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
)
Bug fixes
Allwmake
always uses the bash
Make sure that On Ubuntu /bin/sh
is something else and the scripts fail.
Hardcode to /bin/bash
downloadSimpleFunctionObjects.sh
still in Makefile
This script (which was removed long ago) was still referenced in
the Makefile
.
grad
in fields added dimensions
grad
and other operators from fvc
added dimensions to values
that were supposed to be dimensionless. This has been fixed
condition
for surface fields wrong size in funkySetFields
Default Due to a typo the constructed condition field was too short for surface-fields (too long for volume-fields, but that didn’t matter)
mappedFvPatch
not treated like regular patches
The field-driver created patch fields there as calcuated
when
zeroGradient
would have been more appropriate
flip()
for faceSet
not correctly calculated
A SortableList
was used which meant that the vector with the
flip values was not in the correct order
fset()
crashes when faceSet
has boundary faces
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)
groovyBC
produced incorrect results with wallHeatFlux
etc
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
)
faField
Global variables not found in The Lexer correctly identified the variable but the getField
method did not know how to get it.
Fixed
funkySetAreaFields
Wrong type of condition field in If no condition was evaluated the utility generated a pseudo-field of the wrong length
calculated
-patches $0$ for some operations
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
sqr
of a vector
should produce a symmTensor
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
).
funkySetFields
produced wrong values on processor patches
Patch fields were not copied any no correctBoundaryField
was
called for technical reasons.
Fix: values copied by hand
sortedToc
does not exist for 1.6-ext
Introduced a preprocessor symbol that allows using sortedToc on newer versions
size()
and pointSize()
reported for FaField
-driver
Wrong This was due to a strange () (still don’t know what happened there)
Memory leak in the field drivers
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
/bin/sh
Maintenance scripts not working with non-=bash= 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
cof
and diag
undefined
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)
No new file created if number of patches for patchAverage changes
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
variables
intolerant on spaces
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
div
-operations
Missing 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
expressionField
written too late
Fields created by 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
storedVariables
did not require a initialValue
Now an initial value is required (instead of the default empty string which caused parser failure)
expressionField
fail
Dimension checking makes 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
expressionField
at last timestep not written
The functionObject does not write (and calculate) the field at the last timestep.
Fixed with an one-liner
groovyBC
makes interFoam
-runs fail unpredictably
Reason was an uninitialized valueFraction
which sometimes has
values that cause a floating point exception. Fixed
Global variables of different sizes break parallel runs
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
readAndUpdateFields
were written one timestep too late
Fields treated with Fields were not written after the boundary condition was updated. Now they are
Enhancements
variables
etc
Topology-operators now support 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)
manipulateField
being written
Fields touched by 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
onPatch
and internalFace
added to field-expressions
Indicator functions The function onPatch(name)
returns a surface-field that is name
.
The function internalFace()
is
pow
Non-uniform second argument for Now the second argument to the pow
-function can be a
non-constant
Added transpose to the tensors
The expression A.T()
transposes the tensor A
(for symmetrical
and spherical tensors it leaves them untouched)
I
to parsers
Added unit tensor If no field I
is defined then this is used as the unit-tensor
Added the Hodge dual operator
The unary operator *
calculates for tensors and symmetrical
tensors the hodge dual
replayTransientBC
can now switch on function-objects via dictionary
The optional entry useFunctionObjects
switches on the execution
of function objects during the calculation
replayTransientBC
can now create a phi
-field via dictionary
The optional entry addDummyPhi
creates a phi
-field
expressionField
now allows the specification of a dimension
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)
New features
Allow dynamically loaded plugins that add new functions to parsers
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.
functionObjects
Dynamically generated lists of 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
readAndUpdateFields
Function object 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)
basicSource
Source terms based on 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
Function objects that stop a run gracefully
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)
Function-objects to load thermophysical and turbulence models
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
Function-objects that create and evolve clouds of lagrangian particles
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
)
manipulatePatchField
to manipulate the field on patches
Function-object This function objects allows the manipulation of patch fields
like manipulateField
allows the manipulation of the internal
field. Only use if desperate
Delayed variables to simulate responses
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
funkySetFields
Allow preloading of fields in 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)
Infrastructure
SWAK4FOAM_SRC
Compilation script checks 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
Allwmake
creates symbolic links in swakFiniteArea
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
Reformatting of the parser sources
Sources of the parsers have been completely reformatted to make them more readable and maintainable
swak4FoamParsers
into sub-directories
Move non-parser sources in Make the directory a little bit cleaner
2013-02-28 - version number : 0.2.2
Incompatibilities to previous versions
Python-integration library renamed
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
expressionField
and manipulateField
Change in write behaviour of Now the outputControl
-entry is honored. If set wrong the field
is no longer calculated/manipulated at every time-step
Bug fixes
2.x-branch did not compile on 2.0
Branch only compiled on 2.1, but not on 2.0 due to changes in the OpenFOAM-API
Fix provided by Bruno Santos
groovyBC
: value
reset to $0$ during construction
If no refValue
is given during construction then a value of
Fixed by using the value
as the refValue
if no refValue
is
specified
value
in addGlobalVariables
produces obscure error message
Unspecified 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
Did not compile on 1.6-ext does not consider the product of two symmetrical tensors to be symmetrical. Fixed
Python integration did not get global variables
Change in the interface of the ExpressionResult
-class
broke the access of global variables from a
Python-functionObject. Fixed
maintainanceScripts/makeSwakVersionFile.py
failed when no Mercurial is installed
This didn’t influence the compilation (as there is already a current version file there) but confused people.
internalField
only worked correctly for volume fields
Non-uniform variables for 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
faceFields
causes division by zero
Division of 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
.
valuePatches
did not work for mapped patches
This kind of patch was not identified as something that could have the value fixed
CommonValueExpressionDriver.C
Recent versions of 2.1.x break compilation of The definition of the operator lessOp
clashed with another
definition. Renamed.
Fix provided by Bruno Santos
expressionField
and manipulateField
did not honor the outputControl
-entry
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
namespace Foam
makes compilation of groovyJump
fail with icc
Double Seems like this one was overlooked because gcc
is more
tolerant towards stupidity.
Reported by Edo Frederix
New Examples
Cases from the OSCFD12 Conference in London
On the slides the case files were promised
New features
Access fields from different cases
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
.
Patch-expressions now support mapped-patches
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.
Function objects that manipulate time
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
Plugin-functions for chemical model
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
Plugin-functions for radiation model
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
.
Enhancements
Python-Integration now supports numpy-arrays
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
writeCode=/=writeFile
for pythonIntegrationFunctionObject
Optional parameter If this is set then this Python-code is executed every time a time-step was written to disk
Python-integration has convenience-functions to create data files
Python-integration now has two convenience-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
funkyDoCalc
Switch off dimension checking in A command lione switch -noDimensionChecking
is added that
allows switching off the checking of dimensions if this makes
expressions fail
funkySetFields
allows accessing fields from another mesh
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)
funkyDoCalc
allows specifying foreign meshes
Each expression can specify foreign meshes with a
foreignMeshes
-subdict
Function objects to load and update foreign meshes
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
replaxTransientBC
outputs timestep
This helps debugging timestepping-strategies
weightedAverage
New accumulation 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
.
expressionField
reports name and type of the created field
The title says it all. Should give the user additional feedback about what is happening
groovyPartialSlip
in groovyStandardBCs
New boundary condition This boundary allows specifying the partial slip fraction of the
regular partialSlip
-BC with an expression.
funkySetFields
allows switching off the correction of BCs
This is sometimes necessary to allow calculations with fields where the boundary conditions have a lot of dependencies (turbulence model, other mesh etc)
funkySetFields
Allow selection of additional regions in 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
.
-preloadFields
-option to funkySetFields
Adding a 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
replayTransientBC
now supports all volume types
Support for tensor-types has been added
replayTransientBC
preloads fields
For boundary conditions that require other fields these can be loaded into memory
replayTransientBC
allows selection of time-steps
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.
Infrastructure
Allwmake
stops if building of swak4FoamParsers
fails
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
swak.H
with version information and macros
Header This new header includes information about the
swak4Foam
-version, the OpenFOAM
-version and macros for
workarounds that depend on the OpenFOAM-version
accumulations
-entries converted to NamedEnums
This forces the entries to be checked while being read. Allowing more consistent treatment
Additional maintenance script for special python-versions
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)
Cosmetics
Changes without consequences for the user
name
in parsers to word
Change type of The valid characters for an identifier were the same as in word
(was string
before)
README
and sources
Updated contributor lists in The list of contributors to each file have been added (mostly by script with the information from the repository)
Rewritten methods that return pointers
This abomination from the early days of funkySetFields
has been
cleaned
Documentation
Changes to the documentation
Start of the reference-manual
A first version of a reference manual is added. Only the first part about expressions and parameters is written.
2013-03-18 - version number : 0.2.3
Supports OpenFOAM 2.2
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)
Incompatibilities to previous versions
simpleFunctionObjects
and simpleLagrangianFunctionObjects
no longer independent from rest
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.
Bug fixes
1.6-ext
again
Compiles on The last release (0.2.2) did not compile on 1.6-ext
. This is
fixed
Missing field files for the OSCFD2012-cases
Due to a stupid .hgignore
the 0.orig
-directories were
missing. Nobody complained though
2.0.x
Did not compile on This has been fixed
New features
Writing of sampled surfaces and sampled sets
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.
Enhancements
eigenValues
and eigenVectors
Parsers now support These function and some other minor ones (sph
, dev2
,
twoSymm
) are now supported by the parsers
Extract rows from tensors with component operator
The component operators .x
, .y
and .z
now extract the rows
from a tensor
Variable names that are identical to fields trigger a Warning
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
.
2013-05-24 - version number : 0.2.4
Incompatibilities to previous versions
postProcessing
instead of case folder
Data directories now generated in folder 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
ExpressionResult
from old versions are not correctly read
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
Adaption of cases to 2.2
This may break them for previous versions of OpenFOAM
Infrastructure
Additional flags for the compilation of the parsers
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
bash
instead of sh
in maintainance scripts
Use Some distributions don’t use good old bash
as the default
shell. This breaks some scripts in subtle and not so subtle ways
Build-script prints swak-version in the beginning
To filter bug-reports with outdated versions
Cosmetics
Changes without consequences for the user
word
for names instead of string
Methods use Methods that look for fields now use the appropriate data type
Bug fixes
Compilation on Fujitsu (and probably Intel) compilers
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
executeIf
-function objects are executed if readDuringConstruction
is set to true
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
Expression results are not correctly read from binary file
This was fixed by writing the fields properly with
writeValue
. This may introduce a little incompatibility when
reading files written by old versions
vol()
were registered
Generated fields like These fields were registered with the mesh which might have disturbed similar named real fields. Also did the fields generated for variables get registered
potentialPitzDaily
-case
Missing files in Missing initial conditions made this case a bit pointless
log(vol())
gives floating point exception
This was due to the boundaries being set to 0. Fixed. Also for
the dist()
function
New features
searchableSurfaces
Library with additional 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
StackedExpressionResult
New variable type 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
dumpGlobalVariable
Function object Dumps the value of a global variable into a line of a file
removeGlobalVariable
Function object Removes a global variable (mainly used to preserve memory)
aliases
for parser specifications
Optional entry 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.
Function object to dump registered objects
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?”)
Function object that only executes its children if the run is serial/parallel
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.
Function objects to calculate distributions
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
Enhancements
ExpressionResult
Global variables now can be subclasses of This allows other variable types like stored variables to be inserted there. They are also now saved for restarting
endTime
now added to Python-wrapper
All classes using the python interpreter now have a variable
endTime
with the current end-time value
endTime
set by time-manipulation is reached
Force write if 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
patch
from the simpleFunctionObjects
now accept regular expression
Function-objects based on 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
simpleFunctionObjects
More flexible output control for functionObjects based on 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
swakDataEntry
improved
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
2014-01-24 - version number : 0.3.0
The reason for the jump in the minor revision number is that with
the introduction of the parser for lagrangian particles (cloud
)
the last white spot as far as major data structures in OpenFOAM is
“explored”
Incompatibilities to previous versions
1.6-ext
lost
Support of old Due to certain differences this version only compiles with the
nextRelease
-branch of 1.6-ext (from the git
).Usually the
failing parts can be fixed b commenting out the appropriate
#define
in Libraries/swak4FoamParsers/include/swak.H
.
New supported versions
Added support for Foam 3.0
As this version is quite similar to 1.7 a lot of #ifdefs
were
introduced by this port leading to a possible unification with
the 1.x-branch
Infrastructure
Allwmake
more verbose
Make error messages in The error messages where already quite verbose. But people didn’t understand them and asked the same questions over and over …
simpleFunctionObjects
no longer considered an independent project
As there are going to be more cross-dependencies the
simpleFunctionObjects
now have to be part of swak. Changes to
the compile-scripts reflect this.
Allwmake
makes sure that swak is compiled for the same installation
The script writes the version it is used with to disk and at later compiles that this is the same (this makes sure that not a wrong version is used inadvertently to compile)
Additional macros for Debugging output
There are two macros defined that inside an object write the name of the class and the address of the object (if debug is enabled). This makes the output easier distinguishable from the output from other classes/objects. The two macros are:
- Dbug
- Writes the debug information only on the master processor
- Pbug
- Writes the output on all processors and for parallel runs prefixes the processor number
Both macros are to be used like regular streams and don’t have
to be enclosed in if(debug){}
(this is part of the macro)
flex
Separate option for compiling the output of With some compilers (Intel) and aggressive optimization the
lexers (whose code is generated by flex
) have uninitialized
memory and segmentation faults. In these cases now an environment
variable SWAK_COMPILE_LEXER_OPTION
to set lower optimization
for these compilers. For example:
export SWAK_COMPILE_LEXER_OPTION=-O0
After that recompile
WM_NCOMPPROCS
Fixing race condition with big For some machines race conditions with compiling the main library has been reported. The reason seems to be that some source files need headers generated while compiling the grammar. If due to the large number of simultaneous compilation processes the headers have not been generated when these files are compiled the compilation fails.
This effect could not be reproduced on the development machine (but that doesn’t mean that this doesn’t happen on some machines). Nevertheless for the libraries where this might be the case the number of compilation jobs is limited to the number grammars in the library.
Better solution to let the Allwmake
-script generate the headers
before the regular wmake
starts.
Updates to Debian-packaging
Several minor additions that should make packaging easier
- Package version now gets the correct distro name (at least on Ubuntu)
- Packaging picks up the correct python-version (2.7 or 2.6 … does anyone use older?)
- Packaging process leaves the
swakVersion.H
alone
Documentation
Important enhancements of the documentation in the
Documentations
-folder
accumulations
Documentation of The possible values of the common accumulations
-lists are
documented
General documentation of the Python-embedding
The general options and the behavior of the Python-embedding are described
Incompatibilities to previous versions
outputControlMode
timestep
renamed to timeStep
Because of report https://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=177 to be consistent with the nomenclature in the ‘regular’ function-objects.
Bug fixes
timeSet
in function-objects
Missing This method has been added in 2.2.x and breaks the compilation of several function-objects
Fix developed by Bruno Santos
sourceImplicit
unstable
For some reason using SuSp
gave unstable results for the
PDE-functionObjects. Changed to Sp
swakCoded
worked at a time
Fixed bug were only one Bug originally reported https://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=179 in. Reason was that the variable describing the type was not correctly set.
swakCoded
Incorrectly read entries in The entries codeEnd
and codeExecute
were not correctly read
but instead the entry codeRead
was read. Fixed
No logical variables found by most parsers
Reported as https://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=172
Only the field parser correctly found logical variables (although
they were stored). Added a method to pick up the variables (the
reason why this part was commented out is that there is no such
thing as a volBoolField
and that is what the regular mechanism
expected)
sampledSurface
not correctly updated at time of write
Reported as https://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=176
In that case the driver was written before the surface was
updated thus generating fields of size update
is
called at various places (to make sure it is called in any instance)
sumMag
-accumulation now working
This accumulation was available but not implemented. Now implemented.
For non-scalar types it is calculated separately for each component
$0$
Calculation of weight fields failed if size on one processor was This was due to a logical error that was propagated through mindless copy/paste (only the Field-driver got it right). Fixed
groovyTotalPressure
does not read value
Because it is not initialized from the superclass when the dictionary constructor is used. Fixed
addDummyPhi
makes funkySetFields
crash
For multiple times the option Because the pointer is already set. Fixed
aliases
not constructed from dictionary
If the dictionary was read after the construction the aliases are not read. Fixed by moving this reading to the tables reading which is used in every time a dictionary is involved
evolveXXCloud
Gravity not correctly passed in Passed a value where a reference would have been needed. Fixed
writeOften
writes all the time
Reason for this was a change of the interface of outputTime
not
being propagated to this function-object. Fixed
Python-integration does not return single scalars as uniform
The Python-integration returned single scalars (and vectors) not
as a single value but as a field of length
basicSource
working again for OF 2.1
These were not compiled by accident. Fixed
faceZone
and faceSet
do not correctly work on parallel runs
As reported in http://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=190 if a face-set or zone has faces on a processor boundary incorrect values were produced.
The reason was that boundary faces are treated like internal faces. Also do these faces exist on both processors. This is now fixed. If the face is on a regular boundary patch the value is used. If on a processor patch the value is only used if it is on the owner processor.
notImplemented
in movePoints
and moveMesh
of function objects
Allow user to override This addresses http://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=190
Subclasses of simpleFunction
-objects are not guaranteed to be
parallel-aware (for instance swakExpression
can have problems
with stored variables if the number of cells/faces changes) so
the notImplemented
can’t be removed for good.
The workaround is a rather verbose error message and the
possibility to override notImplemented
with a dictionary-switch
New features
Function object that executes if the OpenFOAM-version is right
The functionObject executeIfOpenFOAMVersionBiggerEqual
only
executes if the OpenFOAM-version is bigger or equal to a
specified version. The arguments majorVersion
and
minorVersion
are required. If patchVersion
is not specified
it will match any version. A git
version (.x
) will match any
patch-version
startTime
Function object that is only executed if the current time is the The function object executeIfStartTime
executes its children
if the current time is the startTime
from the controlDict
(which isn’t necessarily the first time step in a restarted case)
Function object that calculates the potential flow
To be used on an existing field to set reasonable initial conditions
phi
Function object that forces a recalculation of Named recalcPhi
in the simpleFunctionObjects. Usually needed
when some other functionObject manipulates velocity or density
Function object that corrects thermophysical model
Name correctThermo
. Recalculates the thermophysical
model. To be used after manipulating temperature etc
Function objects that recalculate the energy of a thermophysical model
Recalculate enthalpy, sensible enthalpy or internal energy according to the current temperature. This allows making this consistent if the temperature has been manipulated.
For OpenFOAM after 2.2 these are replaced by one that recalculates the energy or enthalpy
Function object that calculates the average of one variable as a function of another
The function object swakExpressionAverageDistribution
calculates the average of one function (the expression
) as a
distribution over another (the abscissa
). An example would be
the average pressure in x-direction with abscissa
being
pos().x
, expression
being just p
and the weight
being vol()
. The weight has to be a scalar. All other
expressions can be any data-type
fieldReport
New utility This utility prints some quantitative statistics about a specified field. Optionally these statistics can also be printed for patches, sets and zones. The data can be written to a CSV-file. Also the distributions of the field can be written.
funkyPythonPostproc
New utility This utility needs a dictionary and a specification of times. For each time it
- loads a list of fields specified in the dictionary
- executes a list of function objects specified in the dictionary
- executes python-scripts
The idea is that the function objects pass data to the python-scripts via global variables and the python-scripts do whatever they like
funkySetLagrangianParticle
New utility This utility allows setting new fields of a lagrangian
cloud. Like funkySetFields
it has two modes:
- Setting one field over the command line. This is triggered by
the
-field
-option - Using a dictionary to specify what is being set. In this mode more than one field and more than one cloud can be set. In this mode there is also the possibility to specify a new cloud. This mode expects variables in global namespaces. On of these variables is the position of the particles, for the other variables fields of the same name will be created. All the variables have to be of the same size. Data where corresponding particle position is outside the mesh is discarded
Enhancements
Additional parser for lagrangian particles
There is now an additional parser to calculate expressions on particles.
This parser is organized in a separate library
libswakLagrangianParser
that has to be loaded to use this
parser.
Depending on whether the cloud in question is already in memory or on disk the data is handled differently:
- if the data is on disc then the basic properties of the cloud
(particle positions etc) are used to initialize the class. Then
all files in the folder of the cloud are read and made
available as field names that are the same as the
file-names. Characters in the file names that are not
compatible with the parser are replaced and created as
aliases. In this mode
swak
has no idea about the data except the name and the type - if the cloud is in memory then a corresponding proxy object is
sought. This proxy object knows which data the cloud has, what
the type is and a short description. It makes the data
available as fields.
swak
has by default proxy objects for most particle classes that come withOpenFOAM
. For unsupported classes and adaptor library has to be written.
When a parser for a cloud is used for the first time a table of all the available fields is printed to the screen with type and description (if available)
Function objects that calculate PDEs can use fields from memory
If the field is found in memory this is used instead of a file read from disc.
Function objects that calculate PDEs can write fields before solving
An additional switch writeBeforeAfter
allows writing the field
before and after solving
outputControlMode
simpleFunctionObjects have addition Mode startup
executes the FO only during construction
else
Conditional functionObjects now have optional It is now possible to add a sub-dictionary else
that is used
to initialize a functionObjectProxy
that is executed if the
condition is not fulfilled. The sub-dictionary inherits all
settings that are not set from the parent-dictionary
swakCoded
now allows addition of data to functionObject
The entry codeData
is now read and inserted into the functionObject
swakFiniteArea
no also have complete tensor-operations
Parsers in The two parsers in that library now also support the complete
set of tensor operations (like eigenValues
etc)
swakExpressionDistribution
now allows non-scalar weights
For expressions whose results is not a scalar now the weight function can either be a scalar or of the same type as the expression (so every component can have a separate weight)
accumulations
More options for A number of possible accumulations have been added. Most of
these are based on distributions. If the weighted
variant is
chosen then the meaning is the more physical one (for weighted
the ‘natural’ weight of the quantity is used. For instance for
cells the cell volume. Otherwise the weight
- weightedSum
- sum of the quantity times the weight. There is
an alias
integrate
for this - median
- The value for which 50% of the distribution are
smaller than this. More robust alternative to
average
- quantile
quantile0.25
for instance is the value for which 25% of the distribution are smaller than it- range
- The difference of the quantile of $\frac{1+f}{2}$ and
$\frac{1-f}{2}$. For instance
range0.9
gives the range in which 90% of the values are (from the quantile 5% to 95%) - smaller
- The fraction of the distribution that is smaller than a given value
- bigger
- The inverse of
smaller
- size
- The size of the underlying entity (usually number of cells, faces, points). For types with more than one components all the components have the same value
- weightSum
- Sum of the weights of the underlying entity. Usually the volume oder the area of it.
Python code files are now searched more flexible
If a file specified with an option like startFile
in a
Python-functionObject (or similar) is not found in the current
directory the path of the dictionary it is specified in is
prepended and the file is searched there
IPython
if possible
Python integration now uses The interactive shell of the python integration now uses
IPython
if it is installed. This improves tab-completion etc
Preload libraries in the Python integration
As problematic libraries could hand during importing these
libraries can be imported in a safe way using the optional
importLibs
-entry which is a dictionary. The keys are the names
under which the imports will appear in the Python-namespace. The
value is optional and the name of the actual library
weight()
Added standard function All parsers now implement a function weight()
that returns the
“natural” weight that is used for instance in the weighted
average (for internal fields that would be for instance the cell
volume)
funkyDoCalc
now writes files
Two kinds of files are optionally written
- CSV-files with the values of an evaluation (each evaluation gets its own file)
- Distributions of the evaluations (in a separate directory for each time)
All the files go into a directory whose name is derived from the
name of the evaluation. The outputs can be switched on with the
options writeDistributions
and writeCsv
. Either
- from the command line: this switches it on for all evaluations
- one “per dictionary”-basis for each evaluation separately
PDE-functionObjects now relax their equations
The PDE-functionObjects now honor the relaxationFactors. If
=steady
is false
then relaxation has to be switched on using
relaxUnsteady
. For the last corrector iteration the equation
is not relaxed unless the parameter relaxLastIteration
is set.
laplacian
-operations in internalField
-parser
Full set of The support of laplacian
operations (especially with a
coefficient that is different from a scalar) was incomplete. Now
all possible coefficient types are supported.
Also in the fvcSchemes
-plugin functions the set of
laplacian
-operators was completed
swakExpression
now has optional mask
Function object If the logical expression mask
is set then only the results
from expression
for which mask
is true
are used for
accumulations
Examples
Moved the OSCFD-examples to a different directory
Started one new directory for all cases from presentations
Added examples from the swak-training at the 8th Workshop
Two new examples
- sandPitsOfCarcoon
- Reenacting a scene from “Return of the
Jedi” with
twoPhaseEulerFoam
- landspeedersInCanyon
- Simulating two landspeeders from “A new
hope” with
simpleFoam
2014-07-11 - version number : 0.3.1
Incompatibilities to previous versions
Additional required code snipplet for some Python-functionObjects
There is now a new code-snipplet required for a number of these function objects. It can be left empty but has to be specified
swakSourceFields
Dimension required for stuff in The expressions used with swakExplicitSource
,
swakImplicitSource
and swakSetValue
now also need a
dimension. This dimension is used to make sure that the user
“knows” the actual dimensions of his source terms
New supported versions
Added support for OpenFOAM 2.3
This version adds support for OpenFOAM 2.3. The major changes were due to changes in the API to
searchableSurface
meshToMesh
And several minor adaptions
Added support for Foam-Extend 3.1
No major changes required. Runtime-selection tables are now sorted too
Infrastructure
Improved macros for Foam versions
This should make swak.H
more readable
Support for private installation of bison
If a directory privateRequirements/bin
is private in the
sources directory then the bison
found there is used. A script
maintainanceScripts/compileRequirements.sh
is provided that
fetches the bison sources, compiles them and installs them there
Documentation
Information about macro-expansion added
A section about thus new feature is added
Bug fixes
swakExpressionAverageDistribution
Invalid entries in distributions from The distribution data was not clipped to the range where actually
data was collected. This is now fixed by adding the notion of an
invalid value to SimpleDistribution
swakExpressionAverageDistribution
not correctly working in parallel
This should now be fixed
fvOptions
in swakSourceFields
now actually working
Because of the missing dimensions until now swakExplicitSource
and swakImplicitSource
were not actually working
fvOptions
did not honor the selectionMode
-entry
Always set source etc for whole region. Now the selectionMode
is honored (for instance only in cellZone
the source term will
be applied.)
patchFunctionObject
fails for some parallel runs
Problem is that when the processor boundaries are used too that the indexing might be inconsistent on the different processors. Fix: coupled boundaries are ignored by default (have to be switched on)
funkyPythonPostproc
not executing function objects
In newer version the execute()
-method of function objects
needs a parameter force
. Fixed
foam-extend-3.1
Temporary fields shadow ‘real’ fields in Due to a small semantic difference in the copy constructor of
GeometricField
a temporary object of the same name shadows the
real field and prohibits that it is written. Fixed by giving the
copy a unique name
New features
groovyFixedNormalSlip
in groovyStandardBCs
Boundary condition These boundary conditions allow specifying a value in normal
direction to the patch while in tangential direction the regular
slip condition is applied. This is implemented for fvPatch
and
pointPatch
. For the pointPatch
the normal direction has to be
specified by the user
funkyWarpMesh
New utility Utility that calculates new point values for the mesh. In the
simplest form the expression is specified on the command line. If
the option -expression
is missing the program looks for a
dictionary which allows more control. If -relative
is specified
points are moved by the result of the expression. The result of
the expression must be a pointVectorField
Function objects that write additional writes depending on the flow conditions
A hierarchy of function objects that trigger additional writes. Once a condition is fulfilled data is either written for a specified interval or as long as the condition is fulfilled. After that a cooldown period is possible. During this period nothing is written.
The concrete function objects are
- writeIfFieldOutside
- writing is triggered if the minimum or
the maximum of a field is outside a specified range. Part of
the
simpleFunctionObjects
- writeIfSwakExpression
- writing is triggered if a logical
expression evaluates to
true
. Stopping and retriggering is also possible with logical expressions. Part of thesimpleSwakFunctionObjects
- writeIfPython
- writing is triggered by a Python-snipplet that
either returns
True
orFalse
. Stopping and retriggering are also possible. Part ofswakPythonIntegration
Allows saving and writing a specifiable number of timesteps before the condition is met (this allows finding out what lead to this)
writeOldTimesOnSignal
with new signal handlers
Function object This function object installs a new signal handler for specified signals.
The function object itself saves the last
fvOptions
New library with Starting with OpenFOAM 2.2 (where the concept of fvOptions
was
introduced) there is an additional library swakFvOptions
with
special fvOptions
(in addition to those in swakSourceFields
):
- executeFunctionObjectsFvOption
- this one does not manipulate the fields (as expected) but “only” runs a list of function objects. Application is for instance to get information during the time-step for algorithms that have multiple iterations in a time-step
- reportAvailableFvOptions
- Does no manipulation of the
solution/equations. Simply reports that a callback has been
called. Application: find out which
fvOption
-calls are used by a solver in which order without going through the sources - reportMatrix
- Does not manipulate the matrix but prints a number of metrics
Macro expansion
For expressions and variable lists there is now the possibility to expand values from the dictionary during reading. The two characters that trigger this are
- $
- like the regular variable lookup in OpenFOAM.In its most
complex form it looks like this
$[(type)spec]
wherespec
specifies where to look for the value (including scoping if the OpenFOAM-version supports it). The optionaltype
specifies how the entry should be interpreted - #
- in variable lists:
#otherList;
includes the variable listotherList
instead of this entry
These expansions allow the construction of reusable snipplets that include information from other parts of the case. For instance (this is only part of the specification)
#include "$FOAM_CASE/constant/g" vecName U; downComponent ( "grav=$[(dimensionedVector)g];" "down=($vecName & grav)/mag(grav);" ); variables ( "#downComponent;" "maxDown=max(mag(down));" );
would calculate the component of a vector field that points in
the direction of the gravity (as specified in the g
-file).
This expansion is done during the expression.
Enhancements
expressionField
now allows setting of dimensions
An optional entry dimension
for the function object now allows
setting the dimension of the resulting field
distToPatch
in Field-parser
New function This function gives the distance in the mesh to a specified face.
Not yet working correctly
panicDump
now allows storing old values
With the switch storeAndWritePreviousState
this functionObject
now can cache a number of timesteps and write these results in
addition to the current timestep
swakExpressionAverageDistribution
records extremes and number of samples
In addition to the average now this Function object also records the minimum and maximum value for each bin. Also the number of samples used in the bin
Python-function objects that return a boolean now have a initialization-snipplet
The function objects executeIfPython
, setDeltaTWithPython
,
setEntTimeWithPython
and writeAndEndWithPython
now expect
code snipplet named init
. This is executed in the beginning and
can be used to set up global variables if these snipplets need
some kind of state. The variables have to be declared global
in
the snipplets that do the actual decision (for technical reason)
fvOptions
-support in PDE-function objects
The function objects solveTransportPDE
and solveLaplacianPDE
now call the regular fvOptions
-callbacks (this allows modifying
the solution in the same way it can be modified for solvers)
Examples
other/simpleBendedPipe
Example to demonstrate funkyWarpMesh
and post-processing on
bended geometries
2015-05-31 - version number : 0.3.2
This is the last release to support OpenFOAM 1.7.x and older
Future changes
These are things that will happen in the next release and will break backwards-compatibility
1.x
-branch
Discontinuation of the As version 1.7
is several years old this release will be the
last release that supports it.
Starting with this release the port_2.x
-branch will become the
default
branch and the 1.x
will become legacy
Fixing examples
Due to the umber of different supported Foam-versions not all the
examples run on all versions and it is not possible to fix them
in such a way that they work on all versions. In the next version
they will by adapted to use the pyFoamPrepareCase.py
utility as
this supports having different Foam versions in one case. As a
consequence most cases won’t run without an installed PyFoam
Incompatibilities
groovyBC
during initialization
Changed behavior of If value
is unset then during initialization the value of the
internal field next to the patch is used. Previous behavior was
to set the patch to
In most cases the new behavior should be better.
internalField
Changed semantics for boolean values in As OpenFOAM does not support geometric fields of type boolean
swak uses scalar fields for storing truth values (only in the
internalField
-parser). The semantics was that a value of 0
means false
. Everything else true
. Logical operators set
true
to false
to true
. All others as false
.
If operators were used properly this should not matter, but
expressions that assume for instance that 0.1
is true
will
now fail. Overall this change improves the stability of logival
expressions
Better detection of single values
The improved detection of single values might break some expressions. Especially for the Python-integration as values that were previously passed as arrays are now being passed as single values
minParticleMass
with minParcelMass
Parser for kinematic parcels replaces This reflects a change in the API of the kinematic lagrangian parcels. The old function has been discontinued to avoid confusions with changed semantics
SIGTERM
automatically switched on for parallel runs in writeOldTimesOnSignal
For parallel runs this signal is now automatically switched in so that other signals are propagated to other processors
swakExpressionAverageDistribution
Changed bin-with in Due to a different calculation automatically calculated bin-widths in this function object might slightly differ from previous calculations
funkyPythonPostproc
writes function object data to a different directory
For the swak-function objects the data is now written to a
directory whose name is based on the input dictionary instead of
postProcessing
.
This might break scripts and other post-processing procedures
that rely on the data being in postProcessing
.
Data generated during the run-time of the solver is unaffected
New supported versions
Added support for Foam-Extend 3.2
Only minor adaptions. Mainly to accommodate the new debug switches
Added support for OpenFOAM 2.4.0
Compiles with OpenFOAM 2.4.0 (and 2.4.x)
Internals (for developers)
internalField
Type of booleans changed for Results that were booleans used to report bool
as their type
for the internalField
-parser. Now they report
volLogicalField
, surfaceLogicalField
or
pointLogicalField
. This makes them consistent with the
possibility of requesting these start symbols and specifying
logical fields in the parameters of a plugin function
Bug fixes
swakExpressionAverageDistribution
fails for small spans
If the span of the abscissa
is too small (almost
median
) not correctly working in parallel
Quantile calculations (including Reason was that SimpleDistribution.calcScalarWeight
did not
reduce
. This is now fixed (and a special switch is introduced
for one situation where this isn’t desirable)
PDE
-function objects broken because of fvOptions
On OpenFOAM-versions with fvOptions
these were broken because
of inconsistent dimensions.
This is fixed: now if a fvOption
is defined the
function-objects also needs rho
and this is passed to the call
of fvOption
when generating the source term
binary
not working (with global variables)
Restart in As reported in https://sourceforge.net/p/openfoam-extend/ticketsswak4foam/225/
Problem seems to be that the HashPtrTable
is not correctly read
in binary
-mode. Workaround is to switch to ascii
before
writing and reading that table and then switch back to the
original mode
Single values were passed as arrays
Single values like min(expr)
were passed as arrays instead of a
single value. This is now fixed. The problem is that now
expressions that rely on the old behavior might break
Distributions not written if there is only a single bin
If all data falls into one bin of the distribution then the distribution was not written. This is now fixed
weightedAverage
for AccumulationCalculation
fails for zero-size fields
Fixed
writeOldTimesOnSignal
fails with writeCurrent
If the current time was already written (because it is part of the stored times) a segmentation fault occurred. This has been fixed by checking whether the current time is already stored
Turbulence plugin-functions did not correct the boundary field
This has been fixed
maintainanceScripts
do not work under Python 3
Some The scripts
makeSwakVersionFile.py
makeCopyrightEntries.py
have been adapted so that they now work with Python 2.x as well as Python 3
distToPatch
now working
Function This function for the field parser gives the distance in the mesh to a specified patch. Distance is defined as minimial sum of cell-to-face distances needed to reach this cell from the named patch
processorX
written in writeTimesOnSignal
Not all If a SIGSEGV
or SIGFPE
were encountered only on some
processors then on the others no data was written because these
signals do not propagate to other processors
Now the signal handler raises a SIGTERM
which is propagated to
the other processors. For parallel runs a signal handler for
SIGTERM
is automatically set up to make sure that on all
remaining processors data is written
Infrastructure
Script for generating releases
Provided by Alexey Matveichev
The script maintainanceScripts/make-releases.sh
rolls a release
and puts it into the directory releases
swakConfiguration
Automatic Provided by Alexey Matveichev
Automatically finds the linking options for Python with
python-config
New features
Additional distance-functions in field-parser
Similar to distToPatch
there are now two additional built-in
functions:
- distToCells
- A logical field is provided. The distance to the
cells for which this field is
true
is calculated - distToFaces
- Same as
distToCells
but with a logical function for the faces
Both functions return cell-values
swakMeshWaveFunctionPlugin
for mesh related distances etc
New function-plugin This library collects functions that are similar to
distFromPath
: they use the MeshWave
-algorithm to calculate
distances and connectivity of the mesh.
Functions in this plugin are:
- meshLayersFromPatch
- Calculates for each cell how many mesh layers it is away from a patch
- meshLayersFromCells
- Calculates the number of layers from a set of cells selected by a logical expression
- meshLayersFromFaces
- Calculates the number of layers from a set of faces selected by a logical expression
- floodFillFromCells
- Number connected regions. Cells selected by a logical expression separate these regions
- floodFillFromFaces
- Number connected regions. Faces selected by a logical expression separate these regions
- cellColouring
- “Colors” the cells in such a way that no two neighboring cells have the same number. Mainly for visualizing the mesh structure. “Neighboring” means “cells sharing a face” not an edge. Therefor it may look at the surface like there are cells with the same color
swakMeshQualityFunctionPlugin
Additional function in Additional functions:
- mqCellFaceNr
- Number of faces for each cell
- mqCellShape
- Field with numbers describing the cell
shape. Values are:
- 1
- Hex
- 2
- Prism
- 3
- Wedge
- 4
- Pyramid
- 5
- Tetraeder wedge
- 6
- Tetraeder
- 0
- no classification. Polygon
Function object for developers that raises a signal at the defined time
The function object provokeSignal
can be used to debug signal
handling. No other possible use is known.
The function object allows defining the signal, the time and - in case of parallel runs - the processors on which the signal should be raised
executeIfSetOrZone
that only executes if sets or zones are present
New function-object This function object executes a lost of function objects if
face/cell/point sets or zones are present. The required zones and
sets are specified in a dictionary setsAndZones
: keys are the
names of the entities the values are the types (like
faceZone
). Only if all objects specified there are present
the function objects are executed.
As a side effect if loadAndCacheMissingSets
is true
than sets
that are not yet found in memory are loaded from
disk. Attention: if no set of that name is found on disk then
it is searched at every time-step. This is a potential
performance problem (it is not a problem if the set is there)
executeIfPatch
that only executes if patches are present
New function object This function object executes a lost of function objects if a list of patches is present.
listMeshData
displays data stored in mesh
Function object This function object shows data that is stored in the
mesh. Mostly solverPerformance
with the residuals of the linear
solvers
solverPerformanceToGlobalVariables
Function object This function object gets a list of fieldNames
and gets the
information about their solver performances. The three quantities
that it gets are
nIterations
- the number of iterations
initialResidual
- residual before iterating
finalResidual
- residual after iterating
For each value three variables are created (assuming the field is
named foo
):
foo_nIterations
- array with all the values. This is usually only usable in the Python-integration
foo_nIterations_first
- value of the first solver performance
foo_nIterations_last
- value of the first solver performance
fvSchemes
and fvSolution
Function objects for manipulating simpleFunctionObjects
now has a base class that allows
manipulating fvSolution
and fvSchemes
in-memory but the
solver behaves as if the file changed on disk. Application for
this is changing parameters like relaxation or discretization
schemes during the simulation. This can be used for instance to
start the simulation with ‘safe’ settings and switch to faster
convergence later.
There is currently only one function object
timeDependentFvSolutionFvSchemes
that implements this (more are
planned). It allows switching to different subdictionaries at
specified time. An example can be found at
Examples/manipulateFvSolutionFvSchemes/pitzDailyTimeSwitched
.
This function object gets a list of times and
sub-dictionaries. At the specified time the values from the
sub-dictionary overrides the values in the original dictionary
(Values not present in the sub-dictionary are left untouched). If
reset
is specified as the name for the sub-dictionary then the
dictionary is set back to the original state.
Enhancements
groovyBC
now has a better initialization if value
is unset
Until no if value
was not set groovyBC
automatically
initialized the boundary to T
to
Now if value
is unset then the value of the patch is
initialized from the value of the internal field next to the
patch. This doesn’t protect from the internal field being
writeFieldsOften
and writeAditionalFields
now write Lagrangian clouds
Function objects With an additional optional argument cloudNames
a list of
clouds to be written can be specified like the fields.
This feature was implemented by E. David Huckaby
-functionPlugins
to funkySetFields
and other utilities
Added option For utilities for which this is appropriate this allows loading
function plugins from the command line (without adding them to
the libs
-entry in the controlDict
). It is assumed that the
name of the library starts with libswak
and ends with
FunctionPlugin.so
.
functionPlugins
for parsers created with a dictionary
Optional parameter If a list of words named functionPlugins
is found then the
string libswak
is added in front and FunctionPlugin.so
is
added at the end and a library of that name is loaded to add the
functions provided there
writeTimesOnSignal
Additional signals added to Now it is possible to handle SIGUSR1
, SIGUSR2
and
SIGTERM
. Only needed for testing
pythonIntegration
does nothing if no code is present
If a code is a string of the length
funkyDoCalc
uses weight
and mask
If a dictionary specifies the entries mask
and weight
then
these are evaluated and used to mask and weight the data
specified in expression
funkyDoCalc
allows setting bin width and number
If specified in the sub-dictionary the entries
distributionMaxBinNr
and distributionBinWidth
allow setting
the number of bins. These values are not used exactly but give
the distribution class a hint. distributionMaxBinNr
takes
precedence
writeOldTimesOnSignal
to allow other processes to finish writing
Timeout in For parallel runs the process that initiates the writing of data
waits for the other processes to write their data. This time can
be specified with a parameter sleepSecondsBeforeReraising
that
has a default value 60
writeAndEnd
-function objects now allow storing and writing previous time-steps
The function objects based on writeAndEnd
now have an optional
switch storeAndWritePreviousState
. If this is set then a number
of old time-steps can be stored and will be written when the run
is terminated.
fvOption
-subclasses now support additional forms of addSup
In 2.3.1 two new forms of addSup
where added to fvOption
(one
for compressible equations. The other one for multi-phase
solvers). Both new forms are supported by all
fvOption
-subclasses in swakSourceFields
and swakFvOptions
swakExpressionAverageDistribution
allows specifying the limits
When the switch dynamicExtremesAbscissa
is false
then the
limits of the distribution can be set with minAbscissa
and
maxAbscissa
. This mainly influences the bin-width. If values
fall outside this range then the distribution is extended to
accommodate these values
simpleDataFunctionObject
now can write to a different directory than postProcessing
Function objects derived from This involves almost all function objects in swak that write data
to postProcessing
. The library now allows setting a different
default. This value can also be set with an optional entry
postProcDir
on a per-function-object basis.
This change is used in the funkyPythonPostProc
-utility to set a
directory name that is based on the name of the input dictionary
(or set with an option). Now if there are function objects used
they will write their data to this directory instead of
postProcessing
(leaving data generated during the running of
the solver alone)
Note: This only works for function objects from swak. “Regular”
function objects will still write to postProcessing
funkySetFields
allows correcting the boundary conditions afterwards
An additional option -correctResultBoundaryFields
corrects the
boundary conditions before writing to disk. In dictionary mode
there is also an option correctResultBoundaryFields
.
This is only needed in rare cases.
Examples
icoFoamCavityWithParcel
as a minimal example for adding lagrangian particles
This case demonstrates how to add lagrangian particles to the simplest tutorial-case
2016-07-17 - version number : 0.4.0
This is the first release that does not support OpenFOAM 1.7.x, OpenFOAM 1.6-ext and older versions anymore
New supported versions
OpenFOAM-dev
Rolling support for This version adds support for OpenFOAM-dev
published at
git://github.com/OpenFOAM/OpenFOAM-dev.git
As this version is constantly changing it might or might not work with the most up-to-date version of the repository.
The port is maintained in a branch feature/port_of-dev
that is
never closed and is periodically merged to the develop
-branch.
Internally the dev
-version is maintained as version 9.9.99
Support for OpenFOAM 3.0
Support for this version has been added (basically all the fixes
from the dev
-branch were guarded with the correct version
foam-extend
4.0
Support for This version is supported by swak4Foam
(compiles and runs)
Support for the OpenFOAM v3.0+ version
This version is supported. For the time being it can be assumed that this version is similar to the regular OpenFOAM 3.0
Bug fixes
fieldReport
doesn’t work with all field names
Fields that have names that are not considered proper variable
names by swak (because for instance the have a dot in the name
like alpha.water
) were not handled by fieldReport
. This has
been fixed
SimpleDistribution
may fail for zero-size fields
Construction of The reason is the initialization with pTraits::max
and that
during the calculation of mag
this causes an overlflow. Fixed
by scaling down to the square root of the maximum
writeFieldsGeneral
Wrong type for cloud in Because of this compilation in 2.2 failed. Fix provided by Bruno Santos
solverPerformanceToGlobalVariables.C
did not compile with OF 2.2
The reason was that the solverPerformance
-class is hidden in
lduMatrix
. Fix provided by Bruno Santos
ThermoTurb
function plugin
Solid thermophysics not available in the For OF-versions where fluidThermo
and solidThermo
have the
same base functions like thermo_Cp
can be used for solids too
lookup
-tables no working in faField
-parser
Because of a bug in the lexer lookup tables did not work. Fixed
swakDataEntry
not correctly written for some versions of OpenFOAM
The macro that guarded the code needed for some OpenFOAM-versions did not include OpenFOAM 3.0. Fixed
executeFunctionObjectsFvOption
always executed for makeRelative
and makeAbsolute
The wrong flags were checked and the function objects were always
executed when even if doMakeAbsolute
and doMakeRelative
were
set to false
. Fixed
WM_LABEL_SIZE=64
Does not compile with A reference to a label
that was passed to a flex
-function
broke compilation because that expects a 32-bit integer. Fixed
replayTransientBC
Tensor-fields not correctly handled by Due to a copy/past-problem all tensor-fields (including symmtrical and spherical) would have caused the utility to fail. Fixed
createSampledSurface
not updated during mesh movement
Surfaces created by The function object ignored the callbacks for moving meshes. It now implements them and forces a regeneration of the surface if the mesh moves
funkySetFields
does not set dimensions
The dimension
-entries were read but not set. This is now fixed
funkySetBoundaryField
does not compress files
The utility now reads the compression state of the original and sets the resulting file accordingly
swakExpression
not working for point fields
Point fields were not correctly returned. This is fixed
Infrastructure
Documentation
org-mode
Adaption of the reference guide for new New version of org-mode
makes changes in the UML-code necessary
New features
2D-lookup tables supported in grammars
Like the optional list lookuptables
it is now possible to have
a list lookuptables2D
with 2-dimensional lookup tables. A table
with the name tbl
can be used like this in expressions:
tbl(expr1,expr2)
. expr1
and expr2
must evaluate to scalar
values of the same entity (cells, faces, points …) and the
expression will evaluate to a scalar.
This feature is based on the interpolation2DTable
that is part
of OpenFOAM since 2.2 but there is a modified version of this
class included in swak4Foam
as there is a problem with the
output in the original version. Currently foam-extend
is not
supported as this is missing some base classes as well
(tableReader
)
Added a function plugin for dynamic meshes
The Plugin DynamicMesh
adds functions to visualize the mesh
movement. The functions are
- dyM_meshPhi
- the mesh
phi
as stored with the mesh. Some distributions write this field anyway - dyM_meshCourant
- Mesh courant number. Replicates the number some solvers print automatically
- dyM_meshVelocity
- Velocity with which the cells are
moved. Reconstructed from the mesh
phi
These functions might failed if the mesh has not been moved yet
so their calls might have to be encapsulated in a
executeIfStartTime
function Object
cell
, face
and pointSet
Function object to load The function object loadTopoSets
loads all the available sets
in the mesh into memory for expressions that need them. Also
allows automatic writing of these sets (switched by writeSets
)
cell
, face
and pointSets
Function object to create and manipulate The function objects manipulateCellSet
, manipulateFaceSet
and
manipulatePointSet
allow the manipulation of these
topoSet
. They do so by evaluating an expression mask
and all
cells (faces, points) for which the expression is true
will be
part of the topoSet. If the topoSet is not present in memory the
function object fails unless the parameter createMissing
is set
to true
. The entry writeManipulated
(default: true
) says
whether the topoSet should be written at write times.
An example of this functionality is found in Examples/other/topoSetDamBreak
Function object that executes other function objects only at write time
The function object executeIfWriteTime
in the
simpleFunctionObjects
executes a list of other function objects
only if the current time is a scheduled write time. The purpose
of this function object is to only execute function objects at
write times that don’t honor the
outputControlMode
-setting. Also does the else
-branch allow
executing only when nothing is written
Added a function plugin for MRF cases
This function plugin makes a number of function from the
MRF
-model available:
- functions to make fields absolute or relative in the
MRF
region - a function to calculate the Coriolis force
All these functions call the MRF-model
simpleCloudFunctionObjects
with function objects for particle clouds
Added library These function objects can be added to particle clouds. In this first version these objects can be added:
- cloudMoveStatistics
- Records simple statistics about the
solution of the cloud:
- How often were faces hit by particles (total, per particle: minimum, mean and average)
- How often were particles moved (same data as face hits)
- How often was each patch hit
Only minimum effort has been spent to consolidate this data across processors (particles may be counted on multiple processors).
The main purpose of this function object is to spot problematic behavior (particles that hit patches repeatedly and don’t move)
The optional parameter
reportHitNr
andreportMoveNr
print out the ids of particles that exceed these thresholds - eliminateCaughtParticles
- Sometimes particles get caught in
“endless loops” (hitting the same patch over and over again
without significant movement). This may slow down
simulations significantly as basically the same impact is
calculated over and over again without any progress. Two
parameters allow eliminating such parcels:
- maximumNumberOfHits
- if the same boundary face is hit more often than this by the particle (without hitting any other faces) then the particle is eliminated. Recommended value: 1000
- minDistanceMove
- Minimum distance a particle has to move when hitting a boundary face. If it moved less the particle is removed. Recommended: $10-9$
If one of the parameters is set to a negative value the criterion is “switched off”
- eliminateOutsideParticles
- Removes particles that are outside the mesh (are not inside any cell). The purpose of this is to eliminate particles that are for some reason not correctly tracked
- correctParticleCell
- Correct the cell of the particle before
the evolution begins.
This should fix problems with moving meshes but is currently not working correctly.
An optional parameter
logCorrected
logs the data of the corrected particles to a file. Only use for debugging or if you don’t expect many incidents - traceParticles
- This function object gets a list of particle
ids. For these particles all data is written whenever a
function object is called.
This function object should only be used for debugging if the behavior of a special particle should be tracked
swakCloudFunctionObjects
with function objects that use expressions for clouds
Add library These function objects can be added to particle clouds and use expressions. The function objects are
- eliminateBySwakExpression
- Evaluates an expression for each
particle. If the expression is
true
then the particle is eliminated. Expression can be evaluated before or after the moving of the particles
streamFunction
added to VelocityField
function-plugin
A function that calculates the stream function in a 2D simulation has been added
Enhancements
smooth
, sweep
, spread
to FvcSchemes
-function plugin
Added function for These functions from fvc
were implemented as
plugin-functions. Mainly to be able to test their behavior. To
check what they do see fvcSmooth.H
in finiteVolume
ThermoTurb
Additional functions in plugin Functions from the public interface of basicThermo
and
turbulenceModel
have been added (like kappa
, kappaEff
etc)
functions
at start
Conditional function objects now allow construction of their With the parameter
constructUnconditionally yes;
in function objects that start with executeIf
it is possible to
construct the lists unconditionally at start instead of waiting
for the condition to be true. If unset then the function objects
default to the old behaviour
manipulateField
-function object can switch off manipulating at start
The regular behavior for this function object is that it does
the first manipulation during construction. This can be switched
off with the setting manipulateAtStartup
in cases where not all
the requirements for correctly evaluating the expressions are
fulfilled during construction
replayTransientBC
now handles surface and point fields
The utility can now read surface and point fields. Surface-fields are not corrected because this is not supported by Foam
replayTransientBC
reads fvOptions
The utility now reads fvOptions
for FOAM-versions that support
it. They have to be switched on with ‘useFvOptions’ as most of
the tine they are not needed (only with function objects that
solve equations)
solveAt
-option never
PDE-function objects now have additional When this option is set then the function-objects are read (including the field) but never solved
replayTransientBC
reports execution time
The utility now reports the time. This is useful when using the utility to test function objects
sourceImplicitUseSuSp
to PDE
-function objects
Added parameter The function objects solveLaplacianPDE
and solveTransportPDE
now have a new parameter sourceImplicitUseSuSp
that allows
switching from using Sp()
(the default) to SuSp()
for the
addition of sourceImplicitExpression
replayTransientBC
can read and update dynamic meshes
The command line option -useDynamicMesh
tells the utility to
read the mesh as a dynamic mesh and update it at every time-step
solveTransportPDE
function object now aware of mesh movement
If the function object detects that it is created with a moving
mesh then it asks for a parameter makePhiRelative
to specify
whether phi
should be made relative to the mesh movement (this
is usually necessary). Then either a velocityExpression
or a
velocityName
has to be specified as well and phi
is corrected
according to the mesh movement
If steady
is true
then phi
is not made relative
funkySetLagrangianFields
allows creating fields of arbitrary types
If a cloud is created and in en entry in expressions
the entry
class
is found then it is assumed that a field of that type
should be created. The expression
is not evaluated but added to
the cloud for each particle.
Note: this does not do any semantic checking and is only to
be used to set constant values for required fields for which
swak
can not evaluate the type
Unconverged steady solution of PDE-function objects are reset
For some reason the linear solver does not converge on the
solveTransportPDE
and solveLaplacianPDE
function
objects. This messes up the solution field. In these cases the
solution field is reset to the last known good solution. If this
behavior is undesired it can be switched off with
restoreNonConvergedSteady
simpleFunctionObjects
Additional output options for function obkjects based on There are now three more options for outputControlMode
:
outputTimeAndStartup
, timeStepAndStartup
and
deltaTAndStartup
. These work like the other options but write
data at the startup-time as well
dumpSwakExpression
now works in parallel as well
This function object used to only dump values from the master processor if used in parallel. Now the values from all processors are dumped in the order of the processors
age
and dTarget
added to KinematicCloud parser
Missing properties Two properties that were missing for that cloud type are now available in the parser
Examples
solverPDE/pitzDailyWithPDE
extended
This case has been modified to a version that was presented at
the PFAU (Austrian User Group Meeting) in 2015. Now it compares
with the scalarTransport
function object that was added to
OpenFOAM.
The case now also calculates the time the fluid needs from the
inlet to the outlet (residenceTime
). Steady as well as
transient
2017-05-31 - version number : 0.4.1
New supported versions
Support for OpenFOAM v1606+
This version is supported in the this version of
swak4Foam
. There is only one problem: there were changes to the
tmp
-template. These changes have been taken care of in the
swak4Foam
-sources. But there are two source files in the
distro that need to be modified (basically adding .ref()
instead of ()
in three places:
src/finiteVolume/finiteVolume/fvc/fvcD2dt2.C src/finiteVolume/fvMatrices/fvMatrix/fvMatrixSolve.C
Therefor the officially released version will never compile
with swak4Foam
but this is nothing that can be fixed in
swak4Foam
(the patch is found in the directory
distroPatches/OpenFOAM-v1606+
)
Support for OpenFOAM 4.0
This version is supported in this version of swak4Foam
. There is
one problem: the released version has two problems that mean that
swak4foam
will never compile on the released version.
Patches fixing these issues are found in the directory
distroPatches/OpenFOAM-4.0
Support for OpenFOAM 4.1
This version is supported in this version of swak4Foam
. No
modifications are required
Support for OpenFOAM v1612+
This version supports OpenFOAM v1612+. The modifications were done by Mark Olesen
Incompatibilities
simpleFunctionObject
and subclasses for multi-region-cases
Changed location of files by The location of files written by these function objects (which
are almost all function objects writing data in the
postProcessing
-directory) has changed: now if the function
object belongs to a region that is not the default mesh the
output is written to a sub-directory with the name of that mesh.
This might break scripts or other tools that people use to process that data
Bug fixes
dummyPhi
causes error message
Destruction of On some distros the destruction of a field stored in an autoPtr
after the destruction of the mesh causes an error message. This
has no effect but is annoying. Fixed
functionObjectListProxy
does not honor outputTime
The function object was executed every time not matter what
outputControlMode
was set. Fixed
bool
results not supported by all drivers
Plugin functions with Until now only the internalField
and the faInternalField
supported boolean results. Now all drivers support them
cloud
possible
No plugin function for Because the static variable/method driverName
was not specified
no plugin functions for clouds could get specified
Wrong syntax in primitive types of plugin-function causes C++-error
If a primitive function for instance expects a label and finds an
unscanable string like x23
then this used to generate a failure
by the C++-library. This gave no indication on the real
problem. Now there is a OpenFOAM-error message with a somewhat
better explanation
simpleFunctionObjects
fail in parallel
Initialization function objects in Because of the wrong order of initialization of these function objects they failed in parallel. Fixed
storedVariables
fails for single values in parallel
Writing This war reported by Philippose Rajan (who also provided a patch) at https://sourceforge.net/p/openfoam-extend/ticketsswak4foam/237/
In parallel if the values was marked as a single value but no
part of the underlying entity was on the processor it was tried
to access the first element of an empty field. The fix was to
write the value
executeIfOpenFOAMVersionBiggerEqual
not correctly working with alphabetic patch versions
If the patch version of the current OpenFOAM-version is not a
number and not x
then this function object failed
mqFaceMaximum
and mqFaceMinimum
in the LocalCalculations
-plugin fail for patch types without values
As patch types like empty
have no values stored this plugin
failed. Now it checks if there is data
simpleFunctionObject
did not pass parent directory correctly
When storing the data for the function object no reference to the parent directory was stored and therefor scoped macro-expansion did not work anymore
ThermoTurb
functionPlugin not working with new thermoType
-format
The thermophysical functions in this plugin did not work if
thermoType
was a dictionary. Fixed
Also: construction of turbulence now gets the rho-field directly from the thermophysics
solidThermo
instances could not use basicThermo
-methods in ThermoTurb
-plugin
Reason was that only two specific thermo-subtypes of
fluidThermo
were searched if the method was not part of
solidThermo
. Now also the basic type is searched
Global variables recognized but not correctly used by some drivers
The drivers for sampled entities, sets and zones found global variables but were not able to use them correctly. Fixed
Cloud function-objects that need a parser not working
The reason is that when constructing the CloudProxy
a cast is
made to the assumed cloud type which in the case of cloud
function-objects is not the actual type. To avoid this separate
instantiations of the CloudProxy
were added
Internals (for developers)
ExpressionResult
now stores single values separately
To fix a problem with writing of single values in parallel (see
above) a union
was added to store the single values. The reason
for this is to avoid a second parallel communication when writing
the value. This adds memory to ExpressionResult
(in the order
of a tenor
object). The memory is not the problem but that the
single value is saved twice (the other time is in the regular
value field)
For compilers that do not support the C++0x-standard instead of a
union
a struct
will be used because non-primitive members for
unions
are only supported for that standard. This will lead to
a slightly higher memory usage (but still small compared to full
fields)
functionObject
removes the start()
-method
Rewrite of OpenFOAM-versions based on the foundation release 4.0 and later
don’t have a start()
-method in the function objects
anymore. Lot of functionality of swak relied on this method. To
make swak compatible across versions start()
is now called in
the constructors of the function-objects (if the OpenFOAM-version
requires it)
Infrastructure
Add the development branch to the version string in utilities
If the compiled version is not a released one then the info of
hg branch
is added to the version output that utilities like
funkySetFields
print
Documentation
Added Compatibility matrix for examples
Different OpenFOAM-versions have different formats for the input
files. This means that examples that work for one version will
break with another version (but is still useful to see how things
are done). The file
Documentation/examplesCompatibilityMatrix.org
gives an
(incomplete) overview on which versions run which examples (some
examples will never run because a certain feature might be
missing in that Foam-version)
Currently 4 Foam-versions are tested
- OpenFOAM 5.0 (the Foundation release)
- Foam-extend 4.0
- OpenFOAM+ 1706
- OpenFOAM 2.3 (to check compatibility with old versions)
Other versions might or might not work. The first three will be replaced with the latest version of that fork once it becomes available
New features
ShiftField
that allows shifting volume fields
Function plugin When adding the library libswakShiftFieldFunctionPlugin.so
to
libs
in the controlDict
functions are added that allow
shifting volume fields by a specified distance. One example
would be an expression
"shiftConstantScalarField(T,(1 1 0))"
which generates a new volScalarField
where the value at (0 0
0)
is the value of T
at the location (1 0 0)
.
The scheme for naming the functions is
scalar<ShiftType><ValueType>Field
with
- ValueType
- one of the base types
Scalar
,Vector
,Tensor
,SymmTensor
,SphericalTensor
- ShiftType
- how the shift is specified. Possible values are either
- Constant
- A constant vector (like the example here)
- Expression
- An expression that gives a
pointVectorField
(for instanceinterpolateToPoint(time()*vector(0,0,-1))
)
These functions work by generating a new mesh that is shifted as specified (in the inverse direction) and interpolating between this and the original mesh. This is computationally very expensive and therefor not recommended in evaluations that occur very often.
Cells that have no shifted equivalent value are set to zero. Boundary patches are not interpolated. Both of these behaviors can cause weird results.
There are also variants with Default
in the end. These allow
setting different default values than
The functions with the names map<ShiftType><ValueType>Field
map
the value of the nearest cell. This is more stable but might
coarsen the field
The additional findShifted<ValueType>Field
-functions do the
mapping by avoiding the meshToMesh
-functions of OpenFOAM: the
shifted value is found by “looking” into the original cell that
contains the point that is the cell center plus the displacement
value. If that point is not in the mesh a default value is used
swakStateMachine
to easily implement switching in cases
Library This library implements State machines. This is a convenient
way to store a state in a simulation and switch between them by
predefined rules. An example for states in a State machine
would be: closed
, valveOpening
, open
, valveClosing
The library has the function objects and plugin functions to use State machines.
The chapter State machines in the Incomplete swak4Foam reference describes it in more detail
stateMachineFvSolutionFvSchemes
to switch numerics accorrding to a state machine
Function object This function object allows modifying fvSchemes
and
fvSolution
according to the states of two state machines.
Quantile
for calculations with the distribution of a function
Function plugin All the functions in this plugin first calculate a distribution. This distribution is calculated from the first parameters:
- the field for which the distribution is calculated
- the weight with which the cell values enter the
distribution. Usually
vol()
(volume weighted) or1
(equal weight for all cells) - a logical expression that specifies which cells are used
(
true
for all cells) - the number of bins to use for the distribution. This specifies
how fine the distribution is calculated. Should be small
compared to the number of cells. Usually the values
100
or1000
should be sufficient
The implemented functions are
- fracSmallerThan
- Writes a fraction in the range from $0$ to $1$ with for instance $0.5$ meaning “50 % of the distribution is smaller than the value in this cell”. The cells which are masked out get the value $-1$.
- fracSmallerThanFromOther
- Like
fracSmallerThan
but there is an additional parameter: the field that is used for calculating the fraction. Here the mask is not used for calculating the fraction (but still used for calculating the distribution) - quantileFromOther
- Basically the inverse of
fracSmallerThanFromOther
. The last parameter is a fraction (from $0$ to $1$) and the result is the corresponding quantile: if a fraction $0.5$ is specified then the value from the distribution for which 50% are smaller is written to the cell
Note: values may slightly vary according to the number of bins. But the bin number also increases the calculation time.
outputTime()
to indicate output time
Function A function outputTime()
has been added to the parsers. This
function is true
if Foam is writing at the current time and
false
else
writeBoundarySubfields
to write subfields of boundary conditions
Utility Sometimes to debug problems with boundary conditions it is good
to look at fields like refValue
in Paraview (for instance
because groovyBC
might not have set that value the way we
expected it). For a field foo
the utility would write a field
foo_bar
if the user specified bar
to be written. The interior
of the field will be bar
is defined will be
fixedValue
with the value of bar
. All others are
zeroGradient
A string with the specificion of the subfields to create fields
for is set with the option -subfields
. The specifications are
separated by =,=. Each specification is of the form
<name>:<type>
(with type being scalar
, vector
, symmTensor
or sphericalTensor
. A type native
assumes that the same type
as the field should be used). If unset the default value is used:
the specification to write all subfields usually associated with
the mixed
boundary condition
It is assumed that the length of the sub-field is equal to the number of faces in the patch
swakDynamicMesh
with “swakified” dynamic mesh subclasses
Library This libraries collects specializations of dynamic mesh classes that work together with OpenFOAM. Currently these classes are in the library:
- swakMotion
- this is a solid body motion solver for the
solidBodyMotionFvMesh
where the translation and the rotation of the solid body can be specified byswak
-expressions - groovyCyclicACMI
- this patch type is a subclass of
cyclicACMI
where the faces that cyclic can be switched on and off with an additional field that is specified with the parameteropenField
in the specification in theboundary
-file. This field has to be present in memory at the first time-step (usually areadAndUpdateFields
-functionObject is a good way to achieve this). The values on the correspondingnonOverlapPatch
of the first boundary in the coupled pair is used to switch faces on and off: if the value of the face is $1$ then it is ‘open’ if it is $0$ it is ‘closed’ - nonMovingFvMesh
- A non-moving mesh that pretends to move. This triggers the recalculation of AMI-interfaces
- groovyBCJumpAMI
- allows implementing a jump condition on an AMI-interface that depends on an expression evaluated on the master patch of the interface
The folder Examples/DynamicMesh
has examples for this library
fvOptions
Record current residual of the equations with The two fvOptions
matrixChangeBefore
and matrixChangeAfter
can be used to record the residual or the change of it.
The residual
matrixChangeBefore
calculates this for a fieldName
and uses for fvMatrix
of
that field. The result is stored in a field whose name is
composed of the value of namePrefix
and fieldName
. This field
can be useful to see where the current solution does not fit the
linearized system
matrixChangeAfter
does the same calculation but assumes that
the field already exists and subtracts the result from the
previous value. So if another fvOption
was applied to the
fvMatrix
between these calls then the field has the change of
this matrix. If “only” a source term was added then this field
corresponds to the source term.
In principle fvOptions
are executed in the order in which they
are specified. If the setting doAtAddSup
is set to true
then
it is executed in an early phase (when source terms are set). If
set to false
then the fvOption
is executed during the
setValues=/=constrain
phase.
setDeltaTBySwakExpression
Setting time-step with an expression: This new function object in simpleSwakFunctionObjects
evaluates
a scalar
expression and sets deltaT
accordingly. Only works
on OpenFOAM-versions that support DataEntry
or its successor
Function1Types
.
Enhancements
Primitive parser for Plugin-functions now supports tensor types
The parser for primitve
types now supports tensor
,
symmTensor
and sphericalTensor
as well.
variables
(under certain circumstances)
Plugin-functions now can use For an expression fooFunmction(var+2)
where fooFunction
is a
Plugin-function the symbol var
can now be a variable: if in the
parent dictionary there is a sub-dictionary fooFunctionData
then this dictionary is searched for a variables
-entry and
these variables are then evaluated (it is also possible to have
lookuptables
and similar in fooFunctionData
)
Timeline function objects now optionally write value at start time
Function objects that inherit from timelineFunctionObject
(like
swakExpression
) now have an optional parameter
writeStartTime
. If set to yes
then the value at start-time
will be written. The default setting is no
. This is similar to
the old behavior and avoids crashes at startup. Some classes
change this default to make it yes
Additional functions in the radiation function plugin
Additional functions for the absorptionEmissionModel
and the
sootModel
are added to to library with the radiation-functions
readAndUpdateFields
: surface fields, output, switching
Improvement of The function object readAndUpdateFields
got three improvements:
- an optional switch
correctBoundary
allows switching the correction of boundary conditions off - surface-fields are now read as well. But no boundary correction is performed as the these fields do not support this
- better output. Instead of silently reading fields or using those in memory the name of the field and the type are written out
executeIfStartTime
now also allows execution if it is “only” a restart
Normally the function object only executes only if this is the
real start time (not a restart). If the option executeOnRestart
is set then the function object also executes if this is a restart
reportAvailableFvOptions
now reports constrain
-methods
On OpenFOAM-versions that support it this now reports if
constrain
is called for an equation
constrain
method added to fvOptions
In earlier OpenFOAM-versions the name of this method was
setValue
. To keep source compatibility this method is kept and
the method constrain
patches through to it. If the fvOption
has SetValue
in the name then this name is kept
simpleFunctionObjects
in multi-region cases now write to sub-directories of postProcessing
To conform with the way that regular OpenFOAM function objects do
it now function objects that belong to the non-default mesh in
multi-region cases write their data to a sub-directory of
postProcessing
named after the mesh
funkyWarpMesh
allows reading function objects
Function objects can now be loaded with an option
-allowFunctionObjects
executeIfStartTime
now also allows execution if it is “only” a restart
Normally the function object only executes only if this is the
real start time (not a restart). If the option executeOnRestart
is set then the function object also executes if this is a restart
storedVariables
and swakDataEntry
Scoped macro expansion now works for When reading these data structures the parent directory is
correctly passed and therefor scoped macro expansions
($[:deltaT]
for instance) works
Examples
FvOptions/heatExchangerSources
Demonstrates getting changes to the solution (residuals) with
matrixChangeBefore
and matrixChangeAfter
State machine examples
- Examples/StateMachine/stateCavity
- demonstrates the basic functionality of state machines
- Examples/manipulateFvSolutionFvSchemes/pitzDailyStateMachineSwitched
- demonstrates using state machines to manipulate the discretization during a simulation
Dynamic mesh examples
The folder Examples/DynamicMesh
has examples that demonstrate
capabilities of the swakDynamicMesh
-library.
- rotatingTank2D
- is a demonstration of a
solidBody
mesh movement where translation and rotation are described by swak-expressions - hecticInletACMI2D,switchedTJunction,switchedInletACMI2D
- demonstrate
a
ACMI
boundary condition where switching of faces is done by a swak-expression. Won’t work withFoam-extend
as this has noACMI
2018-12-29 - version number : 0.4.2
The Foam-versions that this release has been tested with are
- OpenFOAM 2.3
- OpenFOAM 6.0
- OpenFOAM+ v1806
- Foam-Extend 4.0
New supported versions
OpenFOAM+ v1706
Minor adaptions were required to make this compile
OpenFOAM 5.0
Some adaptions were required to make this compile
OpenFOAM+ v1712
Minor adaptions were required to make this compile by Mark Olesen
OpenFOAM+ v1806
Adaptions supplied by Mark Olesen. Adaptions needed after the release
This is one of the versions that this release is tested with
foam-extend 4.1
This is a work in progress based on the nextRelease
-branch as
there is no release yet
This is one of the versions that this release is tested with
OpenFOAM 6
Compiles.
This is one of the versions that this release is tested with
OpenFOAM+ v1812
Adaptions supplied by Mark Olesen.
This will be the officially tested version after this release
Incompatibilities
initPotentialFlow
now named differently
Solved field in The field name is now the name of the original field plus
Potential
. This means that in fvSchemes
discretizations for
that field have to be provided
Environment variables for Python 2 integration renamed
These environment variables are now renamed from _PYTHON_
to
_PYTHON2_
. Scripts are adapted
funkyDoCalc
-files with an entry expressions
assumed to be new format
If one of the dictionaries in the specification file for
funkyDoCalc
is named expressions
it is assumed that the file
is in the new format and calculations will probably fail
Bug fixes
initPotentialFlow
not working in foam-extend
Here the function object failed with a “copy to myself”-error. This has been fixed by changing the name of the temporary field.
unitCylinder
in simpleSearchableSurfaces
Floating point exception in When finding a cutting point in “infinity” then magSqr
failed. Fixed
ReaderParticleCloud
could not read data if particle number changed
These particles could not be read data from different time-steps if the number of particles differed between them. This has been fixed
funkyDoCalc
does not write data files correctly for parallel cases
In parallel cases the same data was written to each
processor
-directory when writing CSV-files or
distributions. This has been fixed so that the data is written
similarly to single-CPU-cases
Allwmake
Horrible spelling mistake in the Reported by Matti Rauter at https://twitter.com/igt_matti/status/989870314241880067 Fixed
groovyBCJumpAMI
not working correctly
Because the reference was returned instead of the tmp
some
values were overwritten
patchFunctionObject
hangs with processorCyclic
boundaries and regular expressions
To enable cyclic
boundary conditions on decomposed cases
processorCyclic
boundaries are created on some
processors. Sometimes these boundaries are picked up by regular
expressions in function objects derived from
patchFunctionObject
(for instance patchExpression
). This
makes the run hang
This has been fixed by checking whether all processors have the same boundaries in the list and stopping if they haven’t requesting the user to be more specific in the regular expressions
Problem compiling on OF 5.0
Fixed a compilation problem on 5.0 that was due to a wrong
assumption about the change of an API in the Random
-class (it
happens one version later). Thanks for reporting it at
https://sourceforge.net/p/openfoam-extend/ticketsswak4foam/244/
to Daniel Pielmeier
Python2
and Python3
integration if Floating Point Exception is enabled
Failing On some platforms if floating point exceptions are enabled then
importing numpy
fails because it seems to use FPEs to detect
properties of the floating point implementation. This makes the
whole program fail.
Only known workaround is switching FPE-trapping off by
export FOAM_SIGFPE=false
Currently there is a warning issued the first time numpy
is
imported to guide the user to the fix
Internals (for developers)
Refactoring of the python integration
The Python integration has now been split into the actual Python 2 integration and a general part to allow the integration of other interpreter languages
Infrastructure
swakConfiguation.automatic
Automatic detection of Python in If swakConfiguation.automatic
is used as swakConfiguation
then the highest available version of Python 2 and Python 3 is
used for the integration of these two languages
Change banner in Sources
The regular OpenFOAM and the obsolete ICE-banner are removed and a new swak4Foam-banner are added to the source files. This modifies almost every file without changing any functionality
Renaming of the Forks
The three main supported forks are now renamed in the #ifdef
- EXTEND
- stays the same
- ORG
- formerly known as
OPENFOAM
. The CFDDirect/Foundation fork - COM
- formerly
PLUS
. The Version maintained by ESI/OpenCFD
Allwmake
Additional output of The current OpenFOAM-version and the version of the sources is printed in the beginning. This should help diagnosing problems
AllwmakeAll
that compiles requirements automatically
Script The script compiles bison
and lua
before compiling
swak4Foam
itself. It also automatically sets
swakConfiguration
to a version that tries to find the scripting
languages automatically
Documentation
New features
Python 3 integration
In addition to the “regular” Python-integration a separate
library swakPython3Integration
has been added which integrates
with Python 3. The “old” Python integration will always be
Python 2. The two integrations have the same features and the
same function objects (in the names the python
has to be
replaced with python3
)
Lua integration
The library swakLuaIntegration
integrates with the Lua
Scripting language the same way that the Python 2 and Python 3
integrations do. The same function objects exist except that in
the names python
has to be replaced with lua
. If fields are
transferred to Lua then they are converted into
Lua-tables. Therefor the performance should be much slower than
the Python-integration where the native data is mapped to
numpy
-arrays
The script ./maintainanceScripts/compileRequirements.sh
compiles a private version of Lua that is automatically used when
the swakConfiguation.automatic
is used
Function object to read and write dictionaries
The function object readAndWriteDictionary
in the
simpleFunctionObjects
reads a dictionary from disk and writes
it with the other data. The main purpose of this function object
is to allow scripting languages to write their data
atan2
added to parsers
The atan2(x,y)
function has been added to all the parsers. This
takes 2 values of which one must be non-zero (they represent a
point in the
Additional logical accumulators
Three new logical accumulators have been added. They are all
aliases or trivial extensions of the existing or
and and
but
sometimes should make the intention clearer
- all
- alias for
and
- any
- alias for
or
- none
- only
true
if everything isfalse
(basicallynot or
)
neighbourPatch
-function for expressions on cyclic
patches
The expression neighbourPatch(foo)
on a cyclic patch gets the
value of foo
on the “other” side of the cyclic. For this the
field has to be a cyclic
or a subclass
Enhancements
solverPerformanceToGlobalVariables
now supports vector fields
With an additional (optional) parameter vectorFieldNames
this
function object now collects information about the performance of
the linear solver for vector fields as well
funkyDoCalc
New file format for funkyDoCalc
now has a new file format. If a dictionary
expressions
is found in the specification file then it is
assumed that the file is in the new format. expressions
are the
contents of the previous format. Additional keys in the file now
allow specifying things that previously only specified on the command line:
- noDimensionChecking
- foreignMeshesThatFollowTime
A list libs
also allows specifying a list of libraries to
load. This allows adding boundary conditions that would otherwise
make the execution fail
funkyDoCalc
allows writing data as a dictionary
The option -writeDict
writes all the results as a
dictionary. It also includes a sub-dictionary with a copy of the
specification file
funkyDoCalc
executes function objects
With the -allowFunctionObjects
the regular function objects
from the constrolDict
are now executed.
If the new file format is used and there is an entry functions
then the function objects specified there are executed (this
allows setting up additional fields etc)
A list preloadFields
allows preloading fields that might be
needed by the function objects
BUG: using separate function objects causes a segmentation fault after the run finished. Probably because the function objects are inconsitently destroyed
groovyBCJump
now works for non-scalar boundary conditions
Now the boundary condition works for non-scalar fields as well
groovyBC
now supports neighbourField(foo)
If used on a cyclic patch then this will get the value of foo
on the other side. Before this raise a Not Implemented
-Error
Attention: foo
on the patch has to be a groovyBC
for this
work (or any other BC that implements patchNeighbourField()
groovyBC
supports immersed boundary conditions in Foam-extend 4.1
Immersed boundaries need special treatment because it is not a “real” boundary that should have a written value
Examples
groovyBC/jumpChannel
to demonstrate groovyBC
on cyclic boundaries
This old test-example has been upgraded to a full example to
demonstrate the use of groovyBC
with the cyclicSlave
-option
and the groovyBCJump
-condition
ImmersedBC/pitzDaily
to demonstrate immersed boundary conditions in foam-extend
This demonstrates that swak-evaluations can be used for the
immersed boundary conditions in foam-extend
2020-06-04 - version number : 2020.06
Moved from semantic version numbers (that didn’t make sense anymore) to a date based version number.
New supported versions
OpenFOAM+ v1906
Adaptions supplied by Mark Olesen.
This is currently the tested version in the ESI/OpenFOAM+ family
OpenFOAM 7
Compiles. Not fully tested
OpenFOAM+ v1912
Adaptions supplied by Mark Olesen.
Incompatibilities
Bison older than version 3.3 no longer supported
The removal of warnings in biosn 3.4 meant that bison 3.2 and older are no longr able to generate C++ sources from the grammar files
Bug fixes
WM_LABEL_SIZE=64
for foam-extend-4.1
Compilation with Fix supplied by Danial Khazaei because compilation of fe 4.1
broke when the label
size was set to 64 bit. Now works with
other distributions as well
Infrastructure
bison
3.4
Support for The grammars have been adapted to generate C++-sources without warnings with bison 3.4. The script to compile requirements has been modified to download and compile this version.
This breaks compatibility with bison 3.2 and older
This is the latest stable release and only a bug-fix
release. luarocks
was upgraded as well
Now if before compiling a command like
export SWAK_PYTHON3VERSION=6
is executed then Python 3.6 is used even if a “better” Python like 3.7 is found. THe same is true for
export SWAK_PYTHON2VERSION=5
(or similar).
If these variables are not set the highest possible Python is used (like it was before)
clangd
if bear
is installed
Generate files for If Bear is installed then it is used to generate the files that
the clang
tools use to find out how files are compiled. This
allows using LSP-based tools during editing (the necessary
settings for Emacs have been added)
Documentation
Adapted contributors section in the README
Removed outdated information, updated links
New features
Expression run-time trigger for runtime-control in ESI-fork
There now is a run-time trigger swakExpression
that allows
switching the runtime-control (for instance stopping the run)
depending on a swak-expression.
This works only for the ESI-fork. It should work with versions
starting at 3.0+ but is currently only available starting with
v1906 (modify swak.H
if you want to enable/test it for older
versions)
The trigger is found in the swakFunctionObjects
-library
makeAxialMesh
added
This (rather old) utility has been added to swak4Foam. Main reason is that this is the easiest way to maintain this utility for new OpenFOAM versions
Examples
groovyBC/nonBreakingDam
to demonstrate macro expansion
This example demonstrates OpenFOAM macro-expansion inside of expression strings
runTimeCondition/simpleSwakCar
to demonstrate runtime-control in the ESI fork
This example demonstrates the runtime-control for function objects that exists in the ESI-fork