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.
The energy transfer associated with phase change has been corrected in
the case that the variable being solved for is internal energy.
Patch contributed by Juho Peltola, VTT.
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.
