This reduces the memory usage of the stitching operation, and simplifies
its interaction with other mesh changers.
The storage of separate original and non-conformal field parts is now
done within a new "conformal" boundary condition. This condition
internally stores two boundary conditions; one for the original patch
values, and one for the non-conformal part. The conformal condition
replaces the condition applied to the original patch on un-stitch when
the non-conformal boundaries are removed. The data stored in the
conformal condition is then used to restore the previous conditions
during the re-stitch process.
This conformal condition supports mapping of various types. This means
both original and non-conformal boundary data gets mapped automatically
as a result of other mesh changes such as automatic refinement.
Consistency changes have been made that ensure that mesh motion,
topology change (refinement), load balancing, mesh-to-mesh-mapping, and
non-conformal stitching can all be run simultaneously.
The only remaining limitation relates to the use of second order time
schemes. It is not possible to use these schemes if both motion and
topology change are in operation. The accuracy and validity of a second
order scheme is also compromised by the case of frequent topology
changes.
Now both the checkMesh utility and functionObject operate in the same manner
with the same controls, executing the same checkGeometry and checkTopology
functions from the new meshCheck library. The controls have been updated and
made more consistent and flexible, in particular by the addition of optional
user specification for the non-orthogonality and skewness error thresholds:
Application
checkMesh
Description
Checks validity of a mesh.
Usage
\b checkMesh [OPTION]
Options:
- \par noTopology
Skip checking the mesh topology
- \par -allTopology
Check all (including non finite-volume specific) addressing
- \par -allGeometry
Check all (including non finite-volume specific) geometry
- \par -meshQuality
Check against user defined (in \a system/meshQualityDict) quality
settings
- \par -region \<name\>
Specify an alternative mesh region.
- \par -writeSurfaces
Reconstruct cellSets and faceSets of problem faces and write to
postProcessing directory.
- \par -surfaceFormat <format>
Format used to write the cellSets and faceSets surfaces
e.g. vtk or ensight.
- \par -writeSets
Reconstruct pointSets of problem points nd write to
postProcessing directory.
- \par -setFormat <format>
Format used to write the pointSets
e.g. vtk or ensight.
- \par -nonOrthThreshold <threshold value in degrees>
Threshold in degrees for reporting non-orthogonality errors,
default: 70"
- \par -skewThreshold <threshold value>
Threshold for reporting skewness errors, default: 4.
Class
Foam::functionObjects::checkMesh
Description
Executes primitiveMesh::checkMesh(true) every execute time for which the
mesh changed, i.e. moved or changed topology.
Useful to check the correctness of changing and morphing meshes.
Usage
\table
Property | Description | Required | Default value
type | type name: checkMesh | yes |
noTopology | Skip checking the mesh topology | no | false
allTopology | Check all addressing | no | false
allGeometry | Check all geometry | no | false
writeSurfaces | Reconstruct and write problem faces | no | false
surfaceFormat | Format for problem faceSets | no | vtk
writeSets | Reconstruct and write problem points | no | false
setFormat | Format used to write the problem pointSets | no | vtk
nonOrthThreshold | Threshold for non-orthogonality errors | no | 70 deg
skewThreshold | Threshold for reporting skewness errors | no | 4
\endtable
Example of checkMesh specification:
\verbatim
checkMesh
{
type checkMesh;
libs ("libutilityFunctionObjects.so");
executeControl timeStep;
executeInterval 10;
allGeometry true;
allTopology true;
writeSurfaces true;
surfaceFormat vtk;
writeSets true;
setFormat vtk;
}
\endverbatim
or using the standard configuration file:
\verbatim
#includeFunc checkMesh(executeInterval=10, allGeometry=true)
\endverbatim
This model builds up phase fraction and velocity fields from multiple
first-order waves, sampled from a selectable wave spectrum.
Usage:
Property | Description | Required? | Default
----------+-------------------------------+-----------+-------------
depth | The water depth [m] | no | great
spectrum | The wave spectrum | yes |
n | The number of times to sample | yes |
| the spectrum | |
span | The fractional range across | no | (0.01 0.99)
| which to sample the spectrum | |
setFormat | The format with which to plot | no | none
| the spectrum | |
Example specification in constant/waveProperties:
waves
(
irregular
{
spectrum PiersonMoskowitz; // or JONSWAP
PiersonMoskowitzCoeffs
{
U19_5 15;
}
JONSWAPCoeffs
{
U10 10;
F 200e3;
}
n 16;
span (0.01 0.99);
}
);
The fact that these names create sources in their associated transport
equations is clear in context, so the name does not need to contain
'Source'.
Having 'Source' in the name is a historic convention that dates back to
when fvModels and fvConstraints were combined in a single fvOptions
interface. In this interface, disambiguation between sources and
constraints was necessary.
The full set of name changes is as follows:
accelerationSource -> acceleration
actuationDiskSource -> actuationDisk
effectivenessHeatExchangerSource -> effectivenessHeatExchanger
explicitPorositySource -> porosityForce
radialActuationDiskSource -> radialActuationDisk
rotorDiskSource -> rotorDisk
sixDoFAccelerationSource -> sixDoFAcceleration
solidEquilibriumEnergySource -> solidThermalEquilibrium
solidificationMeltingSource -> solidificationMelting
volumeFractionSource -> volumeBlockage
interRegionExplicitPorositySource -> interRegionPorosityForce
VoFSolidificationMeltingSource -> VoFSolidificationMelting
The old names are still available for backwards compatibility.
The fact that these names refer to constraints is clear in context, so
the name does not need to contain 'Constraint'.
Having 'Constraint' in the name is a historic convention that dates back
to when fvConstraints and fvModels were combined in a single fvOptions
interface. In this interface, disambiguation between sources and
constraints was necessary.
This change has been applied to the 'fixedValue' and 'fixedTemperature'
constraints, which were formerly named 'fixedValueConstraint' and
'fixedTemperatureConstraint', respectively.
The old names are still available for backwards compatibility.
This simple model generates a mass transfer between two phases
calculated from the following expression:
\dot{m}/V = C \alpha \grad \alpha
Where:
\dot{m}/V | mass transfer rate per unit volume
C | coefficient
\alpha | volume fraction of the source phase
Example usage:
coefficientMassTransfer
{
type coefficientMassTransfer;
phases (liquid vapour);
C [kg/m^2/s] 0.1;
}
This model may be of use in simple situations, but it is primarily
designed to serve as a prototype for more complex and physical
mechanisms of mass transfer between phases.
When an fvModel source introduces fluid into a simulation it should also
create a corresponding source term for all properties transported into
the domain by that injection. The source is, effectively, an alternative
form of inlet boundary, on which all transported properties need an
inlet value specified.
These values are now specified in the property field files. The
following is an example of a 0/U file in which the velocity of fluid
introduced by a fvModel source called "injection1" is set to a fixed
value of (-1 0 0):
dimensions [0 1 -1 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
#includeEtc "caseDicts/setConstraintTypes"
wall
{
type noSlip;
}
atmosphere
{
type pressureInletOutletVelocity;
value $internalField;
}
}
// *** NEW ***
sources
{
injection1
{
type uniformFixedValue;
uniformValue (-1 0 0);
}
}
And the following entry in the 0/k file specifies the turbulent kinetic
energy introduced as a fraction of the mean flow kinetic energy:
sources
{
injection1
{
type turbulentIntensityKineticEnergy;
intensity 0.05;
}
}
The specification is directly analogous to boundary conditions. The
conditions are run-time selectable and can be concisely implemented.
They can access each other and be inter-dependent (e.g., the above,
where turbulent kinetic energy depends on velocity). The syntax keeps
field data localised and makes the source model (e.g., massSource,
volumeSource, ...) specification independent from what other models and
fields are present in the simulation. The 'fieldValues' entry previously
required by source models is now no longer required.
If source values need specifying and no source condition has been
supplied in the relevant field file then an error will be generated.
This error is similar to that generated for missing boundary conditions.
This replaces the behaviour where sources such as these would introduce
a value of zero, either silently or with a warning. This is now
considered unacceptable. Zero might be a tolerable default for certain
fields (U, k), but is wholly inappropriate for others (T, epsilon, rho).
This change additionally makes it possible to inject fluid into a
multicomponent solver with a specified temperature. Previously, it was
not possible to do this as there was no means of evaluating the energy
of fluid with the injected composition.
for thermophysical transport within stationary solid phases. This provides a
consistent interface to heat transport within solids for single and now
multiphase solvers so that for example the wallHeatFlux functionObject can now
be used with multiphaseEuler, see tutorials/multiphaseEuler/boilingBed.
Also this development supports anisotropic thermal conductivity within the
stationary solid regions which was not possible previously.
The tutorials/multiphaseEuler/bed and tutorials/multiphaseEuler/boilingBed
tutorial cases have been updated for phaseSolidThermophysicalTransportModel by
changing the thermo type in physicalProperties.solid to heSolidThermo. This
change will need to be made to all multiphaseEuler cases involving stationary
phases.
Class
Foam::cylindricalInletVelocityFvPatchVectorField
Description
This boundary condition describes an inlet vector boundary condition in
cylindrical co-ordinates given a central axis, central point, rpm, axial
and radial velocity.
Usage
\table
Property | Description | Required | Default value
axis | axis of rotation | yes |
origin | origin of rotation | yes |
axialVelocity | axial velocity profile [m/s] | yes |
radialVelocity | radial velocity profile [m/s] | yes |
omega | angular velocity of the frame [rad/s] | no |
rpm | angular velocity of the frame [rpm] | no |
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type cylindricalInletVelocity;
axis (0 0 1);
origin (0 0 0);
axialVelocity constant 30;
radialVelocity constant -10;
rpm constant 100;
}
\endverbatim
Note:
The \c axialVelocity, \c radialVelocity and \c omega or \c rpm entries
are Function1 types, able to describe time varying functions. The
example above gives the usage for supplying constant values.
This fvModel applies a volume source to the continuity equation and to
all field equations. It can be applied to incompressible solvers, such
as incompressibleFluid and incompressibleVoF. For compressible solvers,
use the massSource model instead.
If the volumetric flow rate is positive then user-supplied fixed
property values are introduced to the field equations. If the volumetric
flow rate is negative then properties are removed at their current
value.
Example usage:
volumeSource
{
type volumeSource;
select cellSet;
cellSet volumeSource;
volumetricFlowRate 1e-4;
fieldValues
{
U (10 0 0);
k 0.375;
epsilon 14.855;
}
}
If the volumetric flow rate is positive then values should be provided
for all solved for fields. Warnings will be issued if values are not
provided for fields for which transport equations are solved. Warnings
will also be issued if values are provided for fields which are not
solved for.
The interface for fvModels has been modified to improve its application
to "proxy" equations. That is, equations that are not straightforward
statements of conservation laws in OpenFOAM's usual convention.
A standard conservation law typically takes the following form:
fvMatrix<scalar> psiEqn
(
fvm::ddt(alpha, rho, psi)
+ <fluxes>
==
<sources>
);
A proxy equation, on the other hand, may be a derivation or
rearrangement of a law like this, and may be linearised in terms of a
different variable.
The pressure equation is the most common example of a proxy equation. It
represents a statement of the conservation of volume or mass, but it is
a rearrangement of the original continuity equation, and it has been
linearised in terms of a different variable; the pressure. Another
example is that in the pre-predictor of a VoF solver the
phase-continuity equation is constructed, but it is linearised in terms
of volume fraction rather than density.
In these situations, fvModels sources are now applied by calling:
fvModels().sourceProxy(<conserved-fields ...>, <equation-field>)
Where <conserved-fields ...> are (alpha, rho, psi), (rho, psi), just
(psi), or are omitted entirely (for volume continuity), and the
<equation-field> is the field associated with the proxy equation. This
produces a source term identical in value to the following call:
fvModels().source(<conserved-fields ...>)
It is only the linearisation in terms of <equation-field> that differs
between these two calls.
This change permits much greater flexibility in the handling of mass and
volume sources than the previous name-based system did. All the relevant
fields are available, dimensions can be used in the logic to determine
what sources are being constructed, and sources relating to a given
conservation law all share the same function.
This commit adds the functionality for injection-type sources in the
compressibleVoF solver. A following commit will add a volume source
model for use in incompressible solvers.
Warnings about initialisation of particles with locations outside of the
mesh and about the positional inaccuracy of NCC transfers are now
accumulated and printed once per time-step. This way, the log isn't
obscured by hundreds of such warnings.
Also, the pattern in which warnings are silenced after some arbitrary
number (typically 100) have been issued has been removed. This pattern
means that user viewing the log later in the run may be unaware that a
problem is still present. Accumulated warnings are concise enough that
they do not need to be silenced. They are generated every time-step, and
so remain visible throughout the log.
This change makes multiphaseEuler more consistent with other modules and
makes its sub-libraries less inter-dependent. Some left-over references
to multiphaseEulerFoam have also been removed.
When the parallel switch is set false (the default), the system call is executed
only on the master processor, if true it is executed on all processors.
Patch contributed by Stanislau Stasheuski, Aalto University.
Description
This fvModel applies forcing to the liquid phase-fraction field and all
components of the vector field to relax the fields towards those
calculated from the current wave distribution.
The force coefficient \f$\lambda\f$ should be set based on the desired level
of forcing and the residence time the waves through the forcing zone. For
example, if waves moving at 2 [m/s] are travelling through a forcing zone 8
[m] in length, then the residence time is 4 [s]. If it is deemed necessary
to force for 5 time-scales, then \f$\lambda\f$ should be set to equal 5/(4
[s]) = 1.2 [1/s]. If more aggressive forcing is required adjacent to the
boundaries, which is often the case if wave boundary conditions are
specified at outflow boundaries, the optional \f$\lambdaBoundary\f$
coefficient can be specified higher than the value of \f$\lambda\f$.
Alternatively the forcing force coefficient \f$\lambdaCoeff\f$ can be
specified in which case \f$\lambda\f$ is evaluated by multiplying the
maximum wave speed by \f$\lambdaCoeff\f$ and dividing by the forcing region
length. \f$\lambdaBoundary\f$ is similarly evaluated from
\f$\lambdaBoundaryCoeff\f$ if specified.
Usage
Example usage:
\verbatim
waveForcing1
{
type waveForcing;
libs ("libwaves.so");
liquidPhase water;
// Define the line along which to apply the graduation
origin (600 0 0);
direction (-1 0 0);
// // Or, define multiple lines
// origins ((600 0 0) (600 -300 0) (600 300 0));
// directions ((-1 0 0) (0 1 0) (0 -1 0));
scale
{
type halfCosineRamp;
start 0;
duration 300;
}
lambdaCoeff 2; // Forcing coefficient
// lambdaBoundaryCoeff 10; // Optional boundary forcing coefficient
// Useful when wave BCs are specified at outlets
// Write the forcing fields: forcing:scale, forcing:forceCoeff
writeForceFields true;
}
\endverbatim
These deltas constructs another sub-delta, using the same keyword (i.e.,
'delta') to select the type of the sub-delta as was used to select the
outer delta. For example:
delta vanDriest;
vanDriestCoeffs
{
delta cubeRootVol;
}
The '<Type>Coeffs' sub-dictionary is now not optional. It cannot be
optional, because if it were omitted then the 'delta' entries would
clash. If the coefficients dictionary were omitted and (for example) the
'vanDriest' entry was chosen, then the constructors would get stuck in
an infinite recursion, with each vanDriest delta just constructing
another vanDriest sub-delta.
The functions module now applies time-step restrictions from the
functions that are running, rather than from the sub-solver. The
sub-solver only exists to be constructed so that its data is available
to the functions. It should not affect the solution process in any way.
