The boundary condition applied to pressure at open boundaries and outlets is switched
from totalPressure to entrainmentPressure. The latter boundary condition is more robust
since it calculates the pressure for inflow using (velocity) fluxes rather than velocity
on the patch.
This function has been changed to volume average, making it appropriate
to use on layered meshes in which the cells have non-uniform geometry
within their layers. A 'weightFields' (or 'weightField') control has
also been added, so that mass or phase weighted averages can be
performed within the layers.
This prevents spurious factors of 1000 from being introduced in
thermodynamic models. It also generalises the system further with
respect to alternative unit sets.
The legacy fvMeshTopoChangersMovingCone removed, replaced by the more general
mesh mapping approach, see tutorials incompressibleFluid/movingCone and
shockFluid/movingCone.
The patch-specific mapper interfaces, fvPatchFieldMapper and
pointPatchFieldMapper, have been removed as they did not do anything.
Patch mapping constructors and functions now take a basic fieldMapper
reference.
An fvPatchFieldMapper.H header has been provided to aid backwards
compatability so that existing custom boundary conditions continue to
compile.
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.
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.
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.
Population balance size-group fraction 'f<index>.<phase>' fields are now
read from an 'fDefault.<phase>' field if they are not provided
explicitly. This is the same process as is applied to species fractions
or fvDOM rays. The sum-of-fs field 'f.<phase>' is no longer required.
The value of a fraction field and its boundary conditions must now be
specified in the corresponding field file. Value entries are no longer
given in the size group dictionaries in the constant/phaseProperties
file, and an error message will be generated if a value entry is found.
The fraction fields are now numbered programatically, rather than being
named. So, the size-group dictionaries do not require a name any more.
All of the above is also true for any 'kappa<index>.<phase>' fields that
are constructed and solved for as part of a fractal shape model.
The following is an example of a specification of a population balance
with two phases in it:
populationBalances (bubbles);
air1
{
type pureIsothermalPhaseModel;
diameterModel velocityGroup;
velocityGroupCoeffs
{
populationBalance bubbles;
shapeModel spherical;
sizeGroups
(
{ dSph 1e-3; } // Size-group #0: Fraction field f0.air1
{ dSph 2e-3; } // ...
{ dSph 3e-3; }
{ dSph 4e-3; }
{ dSph 5e-3; }
);
}
residualAlpha 1e-6;
}
air2
{
type pureIsothermalPhaseModel;
diameterModel velocityGroup;
velocityGroupCoeffs
{
populationBalance bubbles;
shapeModel spherical;
sizeGroups
(
{ dSph 6e-3; } // Size-group #5: Fraction field f5.air2
{ dSph 7e-3; } // ...
{ dSph 8e-3; }
{ dSph 9e-3; }
{ dSph 10e-3; }
{ dSph 11e-3; }
{ dSph 12e-3; }
);
}
residualAlpha 1e-6;
}
Previously a fraction field was constructed automatically using the
boundary condition types from the sum-of-fs field, and the value of both
the internal and boundary field was then overridden by the value setting
provided for the size-group. This procedure doesn't generalise to
boundary conditions other than basic types that store no additional
data, like zeroGradient and fixedValue. More complex boundary conditions
such as inletOutlet and uniformFixedValue are incompatible with this
approach.
This is arguably less convenient than the previous specification, where
the sizes and fractions appeared together in a table-like list in the
sizeGroups entry. In the event that a substantial proportion of the
size-groups have a non-zero initial fraction, writing out all the field
files manually is extremely tedious. To mitigate this somewhat, a
packaged function has been added to initialise the fields given a file
containing a size distribution (see the pipeBend tutorial for an example
of its usage). This function has the same limitations as the previous
code in that it requires all boundary conditions to be default
constructable.
Ultimately, the "correct" fix for the issue of how to set the boundary
conditions conveniently is to create customised inlet-outlet boundary
conditions that determine their field's position within the population
balance and evaluate a distribution to determine the appropriate inlet
value. This work is pending funding.
Both argument and value dimensions can be set for inline-constructable
function1-s. For example, this inline table function:
massFlowRate table [CAD] [g/s]
(
(0 0.46)
(0.17 1.9)
(0.31 4.8)
);
Is equivalent to this dictionary specification:
massFlowRate
{
type table;
xDimensions [CAD];
dimensions [g/s];
values
(
(0 0.46)
(0.17 1.9)
(0.31 4.8)
);
}
In the inline form, the argument/x-dimensions come first, and the value
dimensions second. If there only one dimension set provided, then this
is assumed to be the value dimensions.
The functionality necessary to write in a different unit set has been
removed. This was excessivelty complex, never used in practice, and of
little practical usage. Output numeric data, in general, is not designed
to be conveniently user-readable, so it is not important what unit
system it is written in.
The old fluid-specific rhoThermo has been split into a non-fluid
specific part which is still called rhoThermo, and a fluid-specific part
called rhoFluidThermo. The rhoThermo interface has been added to the
solidThermo model. This permits models and solvers that access the
density to operate on both solid and fluid thermophysical models.
The he*Thermo classes have been renamed to match their corresponding
basic thermo classes. E.g., rhoThermo now corresponds to RhoThermo,
rather than heRhoThermo.
Mixture classes (e.g., pureMixtrure, coefficientMulticomponentMixture),
now have no fvMesh or volScalarField dependence. They operate on
primitive values only. All the fvMesh-dependent functionality has been
moved into the base thermodynamic classes. The 'composition()' access
function has been removed from multi-component thermo models. Functions
that were once provided by composition base classes such as
basicSpecieMixture and basicCombustionMixture are now implemented
directly in the relevant multi-component thermo base class.
Lagrangian's dependency set is simpler than it used to be. There is no
longer a need to maintain a separate library for models that depend on
the momentum transport modelling.
Dictionary entries constructed with #calc and #codeStream can now
conveniently access and use typed variables. This means calculations
involving vectors and tensors and list and field types are now possible.
To access a variable and construct it as a given type within a #calc
or #codeStream entry, put the type immediately after the $ symbol inside
angled brackets <>. So, $<vector>var or $<vector>{var} substitutes a
variable named var as a vector.
Examples:
- Reflect a point in a plane defined by a normal
p (1 2 3);
n (1 1 0);
pStar #calc "$<vector>p - (2*sqr($<vector>n)/magSqr($<vector>n)&$<vector>p)";
- Rotate a list of points around an axis by a given angle
points ((3 0 0) (2 1 1) (1 2 2) (0 3 3));
rotation
{
axis (0 1 1);
angle 45;
}
#codeStream
{
codeInclude
#{
#include "pointField.H"
#include "transform.H"
#};
code
#{
const pointField points($<List<point>>points);
const vector axis = $<vector>!rotation/axis;
const scalar angle = degToRad($!rotation/angle);
os << "pointsRotated" << nl << (Ra(axis, angle) & points)() << ";";
#};
};
- Compute the centre and trianglation of a polygon
polygon ((0 0 0) (1 0 0) (2 1 0) (0 2 0) (-1 1 0));
#codeStream
{
codeInclude
#{
#include "polygonTriangulate.H"
#};
code
#{
const List<point> polygon($<List<point>>polygon);
writeEntry(os, "polygonCentre", face::centre(polygon));
polygonTriangulate triEngine;
triEngine.triangulate(polygon);
os << "polygonTris" << ' ' << triEngine.triPoints() << ";";
#};
};
- Generate a single block blockMeshDict for use with snappyHexMesh with no redundant information
min (-2.5 -1.2 -3.0); // Minimum coordinates of the block
max (2.5 1.2 3.0); // Maximum coordinates of the block
nCellsByL 33.3333; // Number of cells per unit length
// Calculate the number of cells in each block direction
nCells #calc "Vector<label>($nCellsByL*($<vector>max - $<vector>min) + vector::one/2)";
// Generate the vertices using a boundBox
vertices #codeStream
{
codeInclude
#{
#include "boundBox.H"
#};
code
#{
os << boundBox($<vector>min, $<vector>max).points();
#};
};
blocks
(
hex (0 1 2 3 4 5 6 7) $nCells simpleGrading (1 1 1)
);
defaultPatch
{
type patch;
}
boundary
();
Specific names have been given for expand functions. Unused functions
have been removed, and functions only used locally have been removed
from the namespace. Documentation has been corrected. Default and
alternative value handling has been removed from code template
expansion.
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.
Example of checkMesh specification:
\verbatim
checkMesh
{
type checkMesh;
libs ("libutilityFunctionObjects.so");
executeControl timeStep;
executeInterval 10;
}
\endverbatim
or using the standard configuration file:
\verbatim
#includeFunc checkMesh(executeInterval=10)
\endverbatim
Can be used with any solver supporting mesh-motion, in particular the movingMesh
solver module, to check the mesh quality following morphing and/or topology
change.
If the libs entry is not provided and the name of the library containing the
functionObject, fvModel or fvConstraint corresponds to the type specified the
corresponding library is automatically loaded, e.g. to apply the
VoFTurbulenceDamping fvModel to an incompressibleVoF simulation the following
will load the libVoFTurbulenceDamping.so library automatically and instantiate
the fvModel:
turbulenceDamping
{
type VoFTurbulenceDamping;
delta 1e-4;
}
