The new patch field mapping class timeVaryingMappedFvPatchField has been
factored out of the timeVaryingMappedFixedValueFvPatchField BC so that it can be
used to map data onto fields stored within other BCs.
In the process the writeEntryIfDifferent function had to be moved from
fvPatchField to dictionary so that it can still be used in the
timeVaryingMappedFvPatchField class and it made good sense to create the
non-conditional variant writeEntry to simplify the patch field write functions.
This rationalisation has been propagated all other patch fields.
The Qdot field has been removed from all reacting solvers, in favour of
computing on the fly whenever it is needed. It can still be generated
for post-processing purposes by means of the Qdot function object. This
change reduces code duplication and storage for all modified solvers.
The Qdot function object has been applied to a number of tutorials in
order to retain the existing output.
A fix to Qdot has also been applied for multi-phase cases.
This function object writes out the heat release rate field for a
combustion model. This is useful for solvers where combustion is
optional, and which do not therefore write out the heat release rate by
default; e.g., chtMultiRegionFoam and reactingTwoPhaseEulerFoam.
The motion solvers are executed in order and the resulting displacements
accumulated into an overall displacement and the displaced point positions
returned.
This functionality replaces the dynamicMotionSolverListFvMesh class with the
equivalent specification of a "solvers" list rather than a "solver" entry in
dynamicMeshDict e.g.
dynamicFvMesh dynamicMotionSolverFvMesh;
solvers
(
Rotor
{
solver solidBody;
solidBodyCoeffs
{
cellZone region1;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega 100; // rad/s
}
}
}
Piston
{
solver velocityComponentLaplacian;
motionSolverLibs ("libfvMotionSolvers.so");
velocityComponentLaplacianCoeffs
{
component z;
diffusivity inverseDistance 1(wall1);
}
}
);
to rationalise the structure and class names to avoid the need for the confusing
addNamedToRunTimeSelectionTable and use instead use the standard
addToRunTimeSelectionTable to populate the run-time selection table.
This is an inlet-outlet condition where the inlet value differs above
and below a wave interface. It can be used as follows:
inlet
{
type waveInletOutlet;
inletValueAbove 0.01;
inletValueBelow 0.1;
}
The construction of some patch fields has been corrected so that the
patchType setting always propagates on mapping, IO, clone, etc...
Dictionary and mapping-based patch field constructors now call the
corresponding constructor from the base class, regardless of whether
dictionary settings or mapping are actually needed.
A "mappingRequired" flag has been added to some of the base constructors
in order to prevent unecessary mapping of field data and retain the
previous level of optimisation.
Resolves bug report https://bugs.openfoam.org/view.php?id=3144
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.
