Skip to content
Snippets Groups Projects
Commit 1b17784a authored by Andrew Heather's avatar Andrew Heather
Browse files

Merge branch 'feature-expressions' into 'develop'

Feature expressions

### Summary

This branch represents an implementation of what is considered to be the most useful aspects of swak4Foam ([Swiss-Army-Knife for FOAM](https://openfoamwiki.net/index.php/Contrib/swak4Foam)) from Bernhard Gschaider, namely the ability to use text-based expressions instead of coding in C++ for the following cases:
- expression-based boundary conditions (also known as _groovy_ boundary conditions)
- expression-based setFields (also known as _funky_ set fields)

The idea of what we currently term *expressions* was pioneered by
(Bernhard Gschaider) and is now firmly established in `swak4Foam`.
Among other things, expressions attempt to bridge the gap between
using standard, predefined boundary conditions and writing dedicated,
special-purpose ones. Although part of this gap is now covered within
OpenFOAM by using dynamically compiled user coding (eg, coded boundary
conditions), there remains substantial areas where it can be
significantly more convenient to have a series of predefined functions
and expression sytax with some access to base OpenFOAM field
functionality that enables rapid deployment of boundary conditions, or
custom-defined `setFields` without writing code.
A significant portion of `swak4Foam` expressions has been adapted for
direct integration into OpenFOAM. During the integration and rewrite,
we have tried to pare things down to a smaller subset with the aim of
covering 90% or more of the common cases. The remaining cases are left
to be reassessed for extending the *expressions* functionality in the
future, but they also may be better served with other approaches (eg,
with coded conditions) that were not available when `swak4Foam` was
originally conceived.

To the greatest extent possible, the integrated *expressions* have
been designed to avoid name clashes with `swak` so it should remain
possible to use the most recent versions of `swak` without problem.


### Risks

- New functionality, so low chance of regression.
- The scope of the functionality will be revised in the future

### Naming (for `swak4Foam` users)

The following are the *expressions* correspondences to `swak`:

- The `exprFixedValue` and `exprGradient` boundary conditions are
  roughly equivalent to the _groovy_ boundary conditions.

- The utilities `setExprFields` and `setExprBoundaryFields` are
  roughly equivalent to the _funky_ utilities of similar name.

The naming of the boundary conditions and utilities not only reflects
the slightly different input requirements, but simultaneously seeks to
avoid any potential name-clash with `swak4Foam` in a mixed
environment.

The names for the boundary condition dictionary entries tend be
shorter and slightly different (eg, `valueExpr` vs `valueExpression`)
to serve as a small reminder that the *expressions* syntax is slightly
different than the *groovy* equivalents. It also allows the user to
fashion dictionary entries that are sufficient for **both** boundary
condition variants and quickly toggle between them simply by changing
the boundary condition `type`.

See merge request !300
parents 7e275838 44304e07
1 merge request!300Feature expressions
Showing
with 4490 additions and 0 deletions
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment