Skip to content

Latest commit

 

History

History
2118 lines (1996 loc) · 102 KB

README

File metadata and controls

2118 lines (1996 loc) · 102 KB

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.

Contributors etc

Original Author

Bernhard Gschaider (bgschaid@ice-sf.at)

Current Maintainer

Bernhard Gschaider (bgschaid@ice-sf.at)

Contributors

In alphabetical order of the surname

Martin Beaudoin
trackDictionary in simpleFunctionObjects
Martin Becker
The potentialPitzDaily-case (demonstrating a problem with groovyBC)
Oliver Borm
patchMassFlowAverage in simpleFunctionObjects
Peter Keller
sprinklerInlet-case
Martin Kroeger
mtv surface writer in simpleFunctionObjects
Andreas Otto
fixed the circulatingSplash-case
Alexey Petrov
pythonFlu-integration
Bruno Santos
  • Compilation with Intel compiler and Mingw
  • Rewrite of mybison and myflex to allow parallel compilation with WM_COMPPROCS

If anyone is forgotten: let me know

According to the commits in the mercurial-repository (and the repositories of the projects from which swak emerged) contributors are (ordered by the year of their first contribution):

  • 2006-2013 Bernhard F.W. Gschaider <bgschaid@ice-sf.at>
  • 2008 Hannes Kroeger (hannes@kroegeronline.net)
  • 2008-2009, 2012 Martin Beaudoin, Hydro-Quebec (beaudoin.martin@ireq.ca)
  • 2010 Marianne Mataln <mmataln@ice-sf>
  • 2010 Oliver Borm (oli.borm@web.de)
  • 2011 Alexey Petrov <alexey.petrov.nnov@gmail.com>
  • 2011 Petr Vita <petr.vita@unileoben.ac.at>
  • 2012 Bruno Santos <wyldckat@gmail.com>
  • 2013 Georg Reiss <georg.reiss@ice-sf.at>

Documentation

See: http://openfoamwiki.net/index.php/contrib/swak4Foam

Installation/Compilation

Requirements

  • Version 2.0, 2.1 or 2.2 of OpenFOAM (a version that works with 1.6, 1.6-ext and 1.7 is available separately)
    • The finiteArea-stuff will probably work with version 2.0-ext (once that is available)
  • the compiler generators bison and flex
    bison
    swak4Foam is known to work with bison version 2.4 and higher. Version 2.3 compiles but the plugin-functionality does not work correctly
    flex
    since the introduction of the plugin functions at least a flex version of 2.5.33 is required (2.5.35 is the lowest confirmed version)

Both of these are mainstream packages (they are for instance needed to compile gcc) and should exist on every Linux distribution. Use the package manager of your distribution to install them and only if the compilation process of swak4Foam complains about too low versions try to install them from other sources.

swak4Foam tries to keep the requirements on these as low as possible and sometimes lower versions than the ones reported may work. If they do please report so.

The version of bison can be checked with

bison -V

The version of flex with

flex -V

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). If that file is not present these unconfigured features will not be compiled.

Environment variables that can be set in this file are:

SWAK_PYTHON_INCLUDE
Path to the Python.h file of the used python-installation
SWAK_PYTHON_LINK
Options to link the python-library to the library for the python-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 the swak-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)

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:

  1. SWAK_PYTHON_INCLUDE
  2. SWAK_PYTHON_LINK
  3. 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-namespaces

Assumes that the SWAK4FOAM_SRC environment variable is set to the Libraries-directory of the swak4Foam-sources

solveLaplacianPDE
Solve the Poisson equation

\begin{equation} \frac{∂ ρ T}{∂ t} - ∇ λ ∇ T = Sexpl + Simpl T \end{equation} for $T$ where $ρ$, $λ$ and $S$ can be specified

solveTransportPDE
Solve the transport equation

\begin{equation} \frac{∂ ρ T}{∂ t} + ÷(φ,T) - ∇ λ ∇ T = Sexpl + Simpl T \end{equation} for $T$ where $ρ$, $λ$ and $S$ can be specified. Plus the name of the field $φ$

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)

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.

pythonIntegration

Embeds a Python-interpreter.

pythonIntegrationFunctionObject
Executes Python-code at the usual execution times of functionObjects. The interpreter keeps its state

This library is only compiled if the paths to the Python-Headers are configured in the swakConfiguration-file (see above)

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

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 and sampledSets 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)

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

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’

groovyBC

The old groovyBC-Demos

pulsedPitzDaily

Solver
pisoFoam
Also demonstrates
manipulateField, expressionField and clearField from the swakFunctionObjects. patchExpression from simpleSwakFunctionObjects. solveLaplacianPDE and solveTransportPDE for solving equations, pythonIntegration with calculations using numpy

wobbler

Solver
solidDisplacementFoam

circulatingSplash

Solver
interDyMFoam

movingConeDistorted

Solver
pimpleDyMFoam
Also demonstrates
swakExpression with surface. Due to a problem described below this currently doesn’t work

average-t-junction

Solver
pimpleFoam
Mesh preparation
Execute the script prepare.sh in that directory (requires PyFoam: if not installed change in the boundary-file the type of the defaultFaces to wall)

delayed-t-junction

Solver
pimpleFoam
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 and swakExpression from simpleSwakFunctionObjects.

fillingTheDam

Solver
interFoam
Also demonstrates
Usage of a sampledSet defined in the controlDict 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 with potentialFoam (also a problem connected with that). Provided by Martin Backer

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

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 blockMesh and makeFaMesh
Solver
surfactantFoam (without source term) or swakSurfactantFoam
Demonstrates
FAM-specific swakExpressions and groovyBC (as well as the expressionSource)

other

Cases that don’t have a groovyBC

angledDuctImplicit

Solver
rhoPorousMRFSimpleFoam
Mesh preparation
Execute the makeMesh.sh-script in that directory. If you want to run in parallel call the decomposeMesh.sh-script with the number of processors as an argument
Demonstrates
Usage of the swakTopoSources. Compares different approaches to evaluating with the swakExpression-functionObject. Also an example dictionary that demonstrates the use of funkyDoCalc. 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 the decomposeMesh.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 supplied script prepareCase.sh
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 recalculate gh and ghf

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

PythonIntegration

Demonstrate the integration of Python. Mostly using PyFoam but also with pythonFlu

manipulatedPitzDaily

Solver
simpleFoam
Demonstrates
Usage of PyFoam to manipulate the fvSolution-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 the matplotlib-library

bed2OfPisa

Solver
twoPhaseEulerFoam
Demonstrates
Usage of PyFoam to read the direction of gravity and feeding it into a goovyBC 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
Allrun-script is provided

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 with SwakImplicitSource

Lagrangian

Tests for the functionObjects that create and evolve a cloud of particles (library simpleLagrangianFunctionObjects)

hotStream

Solver
replayTransientBC
Mesh preparation
prepareCase.sh-script
Demonstrates
3 clouds (kinematic, reacting, solidParticle). Loading of a thermophysical model with a functionObject. Plugin functions for information about the clouds

angledDuctWithBalls

Solver
rhoPimpleFoam
Demonstrates
Thermo-cloud. Functions for lagrangian particles

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
Script caseSetup.sh is provided
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)

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

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

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

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://openfoam-extend.hg.sourceforge.net:8000/hgroot/openfoam-extend/swak4Foam

Change to the branch that you want to improve (usually default) and create a new branch

hg branch <branchName>

where <branchname> is an easily identifiable name that makes the purpose of the branch clear (for instance bugfixWrongRandomFunction or featureHyperbolicFunctions). Don’t work on the default branch or any other branches that are not “yours”. Such contributions will not be merged

Once development on the branch is finished export the relevant changesets with

hg export <nodeID>

(nodeID being the ids of “your” changesets) and send them to the maintainer (or attach them to a bug report on Manits). The changes will be reviewed and merged into the default branch (do not attempt to do this yourself). Patches generated with hg export make sure that all changes are attributed to the original developer (you).

An alternative would be the bundle command. Just do

hg bundle <bundlefile>

and then send the bundlefile. This will include all commits that are not in the upstream repository and will allow similar inclusion in the upstream as export.

Once you have proven by successfully submitting changesets via hg export you can ask for write access to the mercurial repository.

Only if you got through Mercurial it can be ensured that your contribution is recognized (if you want to stay anonymous send patches).

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

Special branches

Currently the main branches are:

default
The main branch. This is the brancht that the general public will receive. It compiles under 1.7 and 1.6-ext
port_2.0.x
The branch that compiles under OpenFOAM 2.0. This will eventually become the default-branch
debianPackaging
Branch for generating new Debian-packages of swak4Foam. If somebody wants to “inherit” this: contact the maintainer
finiteArea
In this branch the things for the finiteArea-discretization (only present in 1.6-ext) is developed. Usually gets merged back into the default-branch once a feature is completed

Distributed bug-tracking

As an experimental feature distributed bug-tracking was introduced using the Artemis-extension for Mercurial (see http://hg.mrzv.org/Artemis/). An up-to-date version can be installed by

hg clone http://hg.mrzv.org/Artemis/

somewhere and installing the plugin by editing .hgrc.

This is not the official bug-tracker for swak4Foam. It is used for keeping track of new features that are to be introduced to swak4Foam and may be discontinued if the experiment proves to be unsuccessful.

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

Moving meshes and sampledSurfaces

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 of SampledSurface (marked in SampledSurfaceExpressionDriver.C)
  • Python interpreter (but no calls in swak were found in the stack-trace that could be responsible)

Non-treatment of the inner product & of symmetric tensors

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

History

2010-09-13 - version number : 0.1

First Release

2010-12-18 - version number : 0.1.1

New release Most important changes

Parser for sampledSurfaces

Now expressions for the field on a sampled surface can be evaluated. All sampledSurfaces offered by OpenFOAM now can be used

Multiline variables

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 for areaFields
  • a parser faPatch for patches of areaFields
  • a variant of groovyBC for these patches
  • a computed source faExpressionSource
  • Function-object-variants for areaFields: clearExpression, expressionField and manipulateField. These work the same as their volField-counterparts

Bugfix for compiling in single precision

See https://sourceforge.net/apps/mantisbt/openfoam-extend/view.php?id=49

New function nearDist

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):

New utility funkySetAreaField

Like funkySetFields for finiteArea. Also writes out a volume field for easier post-processing

Refactoring of groovyBC and groovified boundary conditions

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

New utility funkyDoCalc

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:

Rewrite of rand and randNormal

  • These two functions now can receive an integer seed that determines the pseudo-randooom sequence generated by these functions
  • Two functions randFixed and randNormalFixed were added. While the usual rand 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)

Binary min and max

Take the bigger/smaller of two fields. Helps avoid ?:-operations

Allow writing of only volume-fields in funkySetAreaFields

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 $0$ and caused a division by zero

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

Simplified boundary condition groovyBCFixedValue

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

Inject swak4Foam into a distro

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

Absorb simpleFunctionObjects

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

Check for correct bison-version

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 and sphericalTensor

Refactoring of the FaFieldDriver

  • now can also produce edgeFields

No support for tensors yet

Writing of storedVariables

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

General phi in solveTransportPDE

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

Function objects now surfaceField-aware

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

Extension of the expressionToFace topoSet

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

Function object calculateGlobalVariables

Calculates variables and then pushes them to a global namespace

Generate a dummy phi in replayTransientBC

New option added that generates a phi field with value $0$ to keep boundary conditions like 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

Additional options for funkySetFields

Add the options allowFunctionObjects and addDummyPhi to execute functionObjects and add a phi-field (for fields that require these)

Boundary condition groovcBCDirection

Based on the directionMixed boundary condition this allows to set a boundary condition as a Dirichlet-condition only in certain directions while in the other directions it is a gradient-condition

Boundary condition groovyBCJump

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)

Submeshes automatically read if searchOnDisc specified

If a submesh is not yet in memory and the option searchOnDisc is set, the mesh is automatically read into memory and kept there

Conditional functionObjects

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 ....”)

PDE-functionObjects for finiteArea

Solve transport and laplacian equation

Subclass to DataEntry that uses swak-expressions

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

Region name in simpleFunctionObject.outputs

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)

Temporal operators ddt and oldTime

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 and ddt
patch
only oldTime
cellSet,cellZone
only oldTime
sampledSurface,sampledSet
only oldTime
faceSet,faceZone
oldTime
internalFaFields
oldTime and ddt
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.

Boundary condition groovcBCDirection

Based on the directionMixed boundary condition this allows to set a boundary condition as a Dirichlet-condition only in certain directions while in the other directions it is a gradient-condition

Note: this should have been in the last release but was forgotten to merge into the default branch

Boundary condition groovyBCJump

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

Support for pointFields in the field-parsers

Now can read and generate pointFields.

Detailed features (apart from the standard symbols) are:

  • Function point generates a constant pointScalarField
  • Function pts() returns a pointVectorField with the point positions
  • Functions pzone and pset generate logical fields according to existing pointZones or pointSets
  • Functions interpolateToCell and interpolateToPoint interpolate from pointFields to volFields and from volFields to pointFields

Utilities and functionObjects affected by this are

  • funkySetFields
  • new topoSource expressionToPoint
  • expressionField and manipulateField now can deal with pointFields

Support for tensors in the finiteArea-field parser

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

Additional operators from the fvc-namespace

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.

Field itself can not be used in funkySetBoundaryField

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

Incomprehensible error message in funkySetFields if the field is missing

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)

Missing magSqr in parsers

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__

Enhancement to the trackDictionary-functionObject

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

Make sure that Allwmake always uses the bash

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

Default condition for surface fields wrong size in funkySetFields

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)

Global variables not found in faField

The Lexer correctly identified the variable but the getField method did not know how to get it.

Fixed

Wrong type of condition field in funkySetAreaFields

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 $0$ instead of the number of the next cell. This caused certain calculations to fail (give $0$)

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

Wrong size() and pointSize() reported for FaField-driver

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

Maintenance scripts not working with non-=bash= /bin/sh

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

Missing div-operations

These valid div-operations were missing from the grammar:

  • Divergence of a volume-tensor (all three kinds) producing a vector
  • Divergence of a surface-tensor (all three kinds) producing a volume-tensor

Fields created by expressionField written too late

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)

Dimension checking makes expressionField fail

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

Fields treated with readAndUpdateFields were written one timestep too late

Fields were not written after the boundary condition was updated. Now they are

Enhancements

Topology-operators now support variables etc

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)

Fields touched by manipulateField being written

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

Indicator functions onPatch and internalFace added to field-expressions

The function onPatch(name) returns a surface-field that is $1$ on all faces that belong to patch name.

The function internalFace() is $1$ on all internal faces and $0$ on all patches

Non-uniform second argument for pow

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)

Added unit tensor I to parsers

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 and sampledSurfaces onto a volume-field
  • Execute explicit discretization functions (like grad) but select the used scheme in the function instead of using the value from fvSchemes
  • 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.

Dynamically generated lists of functionObjects

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

Function object readAndUpdateFields

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)

Source terms based on basicSource

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)

Function-object manipulatePatchField to manipulate the field on patches

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

Allow preloading of fields in funkySetFields

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

Compilation script checks SWAK4FOAM_SRC

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

Move non-parser sources in swak4FoamParsers into sub-directories

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

Change in write behaviour of expressionField and manipulateField

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 $0$ is assumed for this and during a preliminary update the value is reset to this value.

Fixed by using the value as the refValue if no refValue is specified

Unspecified value in addGlobalVariables produces obscure error message

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

Did not compile on 1.6-ext

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.

Non-uniform variables for internalField only worked correctly for volume fields

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

Division of faceFields causes division by zero

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 <<<<<<< variant A

Recent versions of 2.1.x break compilation of CommonValueExpressionDriver.C

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

Double namespace Foam makes compilation of groovyJump fail with icc

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 $0$. So an expression like psiChem_updateChemistry(0.0001)+psiChem_RR(CH4) calculates the reaction rate assuming that the timestep is $0.0001$.

Two additional functions that sum up all the reaction rates (this should be $0$) and sum up only positive reaction rates (giving an impression on what is going on)

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

Optional parameter writeCode=/=writeFile for pythonIntegrationFunctionObject

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 conventience-functions that return a filename with the full path and create the directories if necessary. The file is not created (that is the responsibility of the Python-code).

The functions are (name is the name of the function object)

dataFile(fname)
creates a directory <case>/<name>_data/<time>. To be used for data that is written at times that differ from write-time
timeDataFile(fname)
creates a directory <case>/<time>/<name>_data. Should only be used for data that is written only at write-time

Switch off dimension checking in funkyDoCalc

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

New accumulation weightedAverage

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 to average.

expressionField reports name and type of the created field

The title says it all. Should give the user additional feedback about what is happening

New boundary condition groovyPartialSlip in groovyStandardBCs

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)

Allow selection of additional regions in funkySetFields

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.

Adding a -preloadFields-option to funkySetFields

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

Header swak.H with version information and macros

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

Change type of name in parsers to word

The valid characters for an identifier were the same as in word (was string before)

Updated contributor lists in README and sources

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

Compiles on 1.6-ext again

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

Did not compile on 2.0.x

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

Parsers now support eigenValues and eigenVectors

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

Data directories now generated in folder postProcessing instead of case 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

Use bash instead of sh in maintainance scripts

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

Methods use word for names instead of string

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

Generated fields like vol() were registered

These fields were registered with the mesh which might have disturbed similar named real fields. Also did the fields generated for variables get registered

Missing files in potentialPitzDaily-case

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

Library with additional searchableSurfaces

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

New variable type StackedExpressionResult

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

Function object dumpGlobalVariable

Dumps the value of a global variable into a line of a file

Function object removeGlobalVariable

Removes a global variable (mainly used to preserve memory)

Optional entry aliases for parser specifications

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 expression weight with the weight of each value and a logical expression mask. Values are only used if mask is true at the place
patchExpressionDistribution
distribution of expression on a number of patches. As the weight the face-area is used

Enhancements

Global variables now can be subclasses of ExpressionResult

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

Force write if endTime set by time-manipulation is reached

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

Function-objects based on patch from the simpleFunctionObjects now accept regular expression

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

More flexible output control for functionObjects based on simpleFunctionObjects

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