Class
Foam::functionEntries::if
Description
Conditional parsing of dictionary entries.
E.g.
\verbatim
U_inlet 15;
#if #calc "${U_inlet} < 10"
..
#else
..
#endif
\endverbatim
Note:
- only supports single line, '\' is not supported
- condition should be readable as a \c Switch
(supports 0,1, true, false, etc.)
Class
Foam::functionEntries::ifeqEntry
Description
Conditional parsing of dictionary entries.
E.g.
\verbatim
a #calc "0.123";
b 1.23e-1;
#ifeq $a $b
..
#else
..
#endif
\endverbatim
\verbatim
ddtSchemes
{
#ifeq ${FOAM_APPLICATION} simpleFoam
default steadyState;
#else
default Euler;
#endif
}
\endverbatim
Note:
- supports dictionary variables and environment variables
- the two arguments should be two tokens
- the comparison is a string comparison for any word/string/variable,
integer comparison for two integers and floating point comparison for
any floating point number.
- parsing of (non)matching \c #else, \c #endif is not very sophisticated
Contributed by Mattijs Janssens
Registration occurs when the temporary field is transferred to a non-temporary
field via a constructor or if explicitly transferred to the database via the
regIOobject "store" methods.
With the inclusion of boundary layer modelling in the gas, the
separation of wave perturbation from and mean flow became less useful,
and potentially prevents further extension to support similar boundary
layer modelling in the liquid.
The mean velocity entry, UMean, is now needed in the
constant/waveProperties file rather than in the waveVelocity boundary
condition.
An atmospheric boundary layer velocity can now be added to the gas side
of the wave modelling. The wave superposition class has been given a
run-time selection mechanism, and a derivation added which includes gas
atmospheric boundary layer modelling. This modelling is therefore
available in both the wave boundary conditions, and in setWaves.
This functionality can be selected in the constant/waveProperties file
by supplying a "type" entry and a number of parameters controlling the
boundary layer. For example:
In constant/waveProperties:
type waveAtmBoundaryLayer;
// properties specifying the wave modelling ...
UGasRef (10 0 0);
hRef 20;
hWaveMin -2;
hWaveMax 3;
UGasRef is the gas velocity relative to the liquid, at the height, hRef,
relative to the wave model origin. hWaveMin and hWaveMax describe the
range of the wave elevation; it is non-trivial to calculate this from
the wave models themselves, so it is required as an input.
The base wave superposition class can be selected with "type wave;", but
also selects by default when the "type" entry is omitted, so the change
is backwards compatible.
In order to increase the flexibility of the wave library, the mean flow
handling has been removed from the waveSuperposition class. This makes
waveSuperposition work purely in terms of perturbations to a mean
background flow.
The input has also been split, with waves now defined as region-wide
settings in constant/waveProperties. The mean flow parameters are sill
defined by the boundary conditions.
The new format of the velocity boundary is much simpler. Only a mean
flow velocity is required.
In 0/U:
boundaryField
{
inlet
{
type waveVelocity;
UMean (2 0 0);
}
// etc ...
}
Other wave boundary conditions have not changed.
The constant/waveProperties file contains the wave model selections and
the settings to define the associated coordinate system and scaling
functions:
In constant/waveProperties:
origin (0 0 0);
direction (1 0 0);
waves
(
Airy
{
length 300;
amplitude 2.5;
phase 0;
angle 0;
}
);
scale table ((1200 1) (1800 0));
crossScale constant 1;
setWaves has been changed to use a system/setWavesDict file rather than
relying on command-line arguments. It also now requires a mean velocity
to be specified in order to prevent ambiguities associated with multiple
inlet patches. An example is shown below:
In system/setWavesDict:
alpha alpha.water;
U U;
liquid true;
UMean (1 0 0);
This is to make it clear that the value supplied is the scalar mean
velocity normal to the patch, and to distinguish it from other instances
of the keyword "UMean" which take a vector quantity.
The Scaled Function1 removes the need for classes to hold both a value
and a ramping function. If it is desired to ramp up a velocity up to
(10 0 0) over the space of 5 seconds, that can be achieved as follows:
velocity
{
type scale;
scale
{
type halfCosineRamp;
duration 5;
}
value (10 0 0);
}
Also, as a result of this change, the velocityRamping fvOption has
become a general acceleration source, based on a velocity Function1. It
has therefore been renamed accelerationSource.
Class
Foam::dynamicInterpolatedFvMesh
Description
Interpolates pre-specified motion specified as a set of pointVectorFields.
The motion can be provided either as a set of displacement or position
fields and the entry \c displacement specified accordingly.
Usage
Example:
\verbatim
dynamicFvMesh dynamicInterpolatedFvMesh;
displacementLaplacianCoeffs
{
field wantedDisplacement;
displacement yes;
interpolationScheme linear;
}
\endverbatim
This will scan the case for \c wantedDisplacement \c pointVectorFields in
the time directories and interpolate those in time (using \c linear
interpolation) to obtain the current displacement. The advantage of
specifying displacement in this way is that it automatically works in
parallel using \c decomposePar to decompose the set of \c pointVectorFields
provided.
The position and direction of cone injection sites can now be specified
using Function1 to make them change in time, relative to the start of
injection.
An example specification of the relevant entries is shown below.
injectionModels
{
injection1
{
type coneInjection;
position table
(
(0 (-0.1 -0.1 0))
(0.25 (0.1 -0.1 0))
(0.5 (0.1 0.1 0))
(0.75 (-0.1 0.1 0))
(1 (-0.1 -0.1 0))
);
direction table
(
(0 (-1 -1 0))
(0.25 (1 -1 0))
(0.5 (1 1 0))
(0.75 (-1 1 0))
(1 (-1 -1 0))
);
outOfBounds repeat;
// etc ...
}
}
Sub-dictionaries can also be used if the keywords of parameters of the
two functions collide:
injectionModels
{
injection1
{
type coneInjection;
position tableFile;
positionCoeffs
{
file "constant/injection1.positions";
outOfBounds clamp;
}
direction tableFile;
directionCoeffs
{
file "constant/injection1.directions";
outOfBounds repeat;
}
// etc ...
}
}
A check is also done to determine whether a constant function is in use
on a stationary mesh, in order to prevent repeated searching for the
same position, and therefore retain approximately the efficiency of the
previous implementation in simple cases.
for consistency with WM_PROJECT. Now "etc" files are assumed to be in etc
sub-directories of WM_PROJECT_SITE and WM_PROJECT_INST_DIR allowing other files
to be stored in those directories. The search order is now:
Search for files from user/group/shipped directories.
The search scheme allows for version-specific and
version-independent files using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/
- ~/.OpenFOAM/
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/etc/
- $WM_PROJECT_SITE/etc/
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/etc/
- $WM_PROJECT_INST_DIR/site/etc/
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/
\return The list of full paths of all the matching files or
an empty list if the name cannot be found.
Optionally abort if the file cannot be found.
Optionally stop search after the first file has been found.
This change was proposed and agreed by the sponsors of the OpenFOAM project on
the OpenFOAM Hub, see https://openfoam.org/maintenance/
This object calculates a field of the age of fluid in the domain; i.e.,
the time taken for a fluid particle to travel to a location from an
inlet. It outputs a field, named age, with dimensions of time, and
requires a solver and a div(phi,age) scheme to be specified. A number of
corrections for the solution procedure can be set, as well as the name
of the flux and density fields.
Example specification:
age1
{
type age;
libs ("libfieldFunctionObjects.so");
nCorr 10;
phi phi;
rho rho;
}
Example usage:
postProcess -func age -fields "(phi)" -latestTime
This work was supported by Robert Secor and Lori Holmes, at 3M
The selection of the "Final" solver settings is now handled automatically within
the "<equation>.solve()" call and there is no longer any need no provide a bool
argument for specific cases. This simplifies the solution algorithm loop
structures and ensures consistency in behaviour across all solvers.
All tutorials have been updated to correspond to the now consistent rules.
Now for transient simulations "Final" solver settings are required for ALL
equations providing consistency between the solution of velocity, energy,
composition and radiation properties.
However "Final" relaxation factors are no longer required for fields or
equations and if not present the standard value for the variable will be
applied. Given that relaxation factors other than 1 are rarely required for
transient runs and hence the same for all iterations including the final one
this approach provide simpler input while still providing the flexibility to
specify a different value for the final iteration if required. For steady cases
it is usual to execute just 1 outer iteration per time-step for which the
standard relaxation factors are appropriate, and if more than one iteration is
executed it is common to use the same factors for both. In the unlikely event
of requiring different relaxation factors for the final iteration this is still
possible to specify via the now optional "Final" specification.
Description
This boundary condition provides a pressure jump condition, using
the \c cyclic condition as a base.
The jump is specified as a \c Function1 type, to enable the use of, e.g.
constant, polynomial, table values. This boundary condition can operate
in two modes - standard and backward compatibility.
In standard mode, jump is specified as a function of total volumetric
flow rate through the patch. In backward compatibility mode, the boundary
conditions serves as a direct replacement for the fanFvPatchField, where
jump is defined as a function of local velocity.
Usage
\table
Property | Description | Required | Default value
patchType | underlying patch type should be \c cyclic| yes |
fanCurve | fan curve, e.g. \c csvFile | yes |
jumpTable | jump data (backward compatibility mode) | no |
reverse | reverse jump direction | no | false
phi | flux field name | no | phi
rho | density field name | no | rho
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type fan;
patchType cyclic;
fanCurve csvFile;
csvFileCoeffs
{
hasHeaderLine 1;
refColumn 0;
componentColumns 1(1);
separator ",";
file "$FOAM_CASE/constant/pressureVsQ";
}
value uniform 0;
}
\endverbatim
The above example shows the use of a comma separated (CSV) file to specify
the jump condition.
Contributed by Daniel Jasinski
Resolves bug-report https://bugs.openfoam.org/view.php?id=3102#c10159
