For high-speed flow cases benefiting from extrapolated pressure, e.g. IC engine
piston motion the fixedFluxExtrapolatedPressure pressure BC can now be used with
the transonic pressure solution option.
Class
Foam::noSlipFvPatchVectorField
Description
This boundary condition fixes the velocity to zero at walls and assumes
the walls are stationary.
For stationary walls with sliding vertices, e.g. engine liners, the normal
component of the velocity is set from the wall face-flux to ensure
continuity.
Usage
Example of the boundary condition specification:
\verbatim
<patchName>
{
type noSlip;
}
\endverbatim
Class
Foam::coupledMultiphaseTemperatureFvPatchScalarField
Description
Mixed boundary condition for the phase temperature of a phase in an
Euler-Euler multiphase simulation, to be used for heat-transfer with another
region in a CHT case. Optional thin wall material layer resistances can be
specified through thicknessLayers and kappaLayers entries.
See also
Foam::coupledTemperatureFvPatchScalarField
The new tutorial case tutorials/modules/CHT/multiphaseCoolingCylinder2D is a
variant of the coolingCylinder2D case in which a 10% oil droplets in water
mixture flows over and cools a hot cylinder. The case in run with the
foamMultiRun multi-solver executor.
Class
Foam::MRFslipFvPatchVectorField
Description
Rotating wall-velocity condition to be used for a slip-wall rotating with
the moving frame in an MRF (multi-reference frame) or SRF (single reference
frame) case.
SRF cases are simply MRF cases with a single MRF zone which covers the
entire domain.
Usage
Example of the boundary condition specification for an SRF case or MRF
case with a single zone:
\verbatim
<patchName>
{
type MRFslip;
}
\endverbatim
or if the case has several MRF zones the particular zone this patch is in
must be named explicitly, e.g.:
\verbatim
<patchName>
{
type MRFslip;
MRFZoneName rotor;
}
See also
Foam::MRFPatchField
Foam::MRFZone
The nearest, matching and inverseDistance methods are now based on a
shared "nearby" method. This method creates, for each face, a local
stencil of opposing faces for which the bounding spheres overlap. This
has proven far more robust on cases with both conformal and
non-conformal interfaces.
which is set true if the mesh refinement changed since the last time the
refinement history was written so that it can be written only at the following
write time.
Resolves bug-report https://bugs.openfoam.org/view.php?id=3928
Description
Solid thermophysical transport model for anisotropic thermal conductivity
The anisotropic thermal conductivity field is evaluated from the solid
material anisotropic kappa specified in the physicalProperties dictionary
transformed into the global coordinate system using default
coordinate system and optionally additional coordinate systems specified
per-zone in the thermophysicalProperties dictionary.
If the coordinate transformed kappa does not align exactly with the boundary
because the patch face orientations do not conform to the coordinate system
exactly it may be beneficial for convergence and accuracy to enforce
alignment at the boundary by setting the optional \c boundaryAligned to
true.
Usage
Example of the anisotropic thermal conductivity specification in
thermophysicalProperties with two zone-based coordinate systems in
addition to the default:
\verbatim
model anisotropic;
// Force aligned handling of kappa irrespective
// of the calculated patch alignment factors.
boundaryAligned true;
// Default coordinate system
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type cylindrical;
e3 (1 0 0);
}
}
// Optional zone coordinate systems
zones
{
coil1
{
type cartesian;
origin (0.1 0.2 0.7);
coordinateRotation
{
type cylindrical;
e3 (0.5 0.866 0);
}
}
coil2
{
type cartesian;
origin (0.4 0.5 1);
coordinateRotation
{
type cylindrical;
e3 (0.866 0.5 0);
}
}
}
\endverbatim
This change prevents fatal errors occurring during programmatic
construction of a plane object. If an invalid plane is constructed then
this can be tested for using a new plane::valid() method.
Errors are still generated from dictionary construction as before, and
they have been improved to better identify where in the file the
erroneous specification is.
This change fixes some issues associated with meshToMesh mapping. The
cell overlap calculation now detects and skips over degenerate
tetrahedra. Previously, it was generating errors as it tried to
construct planes from the faces of these degenerate tetrahedra.
alphaEff is now an internal field used only for the implicit energy correction
term, kappaEff, q and divq are the general and rational interface to thermal
transport.
XiFoam and PDRFoam now explicitly instantiate a unityLewisEddyDiffusivity
fluidThermophysicalTransportModel as the the unity Lewis number approximation is
hard-coded into the formulation of the energy/composition system.
If checkMesh is executed with the -allGeometry option, then surface
files containing the NCC coverage will now be written out. Coverage is
the ratio between coupled area magnitude and total area magnitude. This
is useful for locating parts of the boundary mesh that are in error.
Errors (such as folds and pinches) typically manifest as a coverage
value that deviates significantly from a value of one.
This is comparable to the writing of AMI patches's weight sums, which
also used to occur when the -allGeometry option was selected.
After direct and regular expression matching the scheme name is now filtered to
remove and group/phase extensions in the name and matched again with the schemes
dictionary.
This significantly simplifies the specification of schemes in multiphase
simulations, instead of the rather messy regular expressions the new method
allows schemes to be specified without the group/phase name extension and the
scheme is then used for all groups/phases. For example in the bubbleColumn
tutorials the schemes can now be specified thus:
divSchemes
{
default none;
div(phi,alpha) Gauss vanLeer;
div(phir,alpha,alpha) Gauss vanLeer;
div(alphaRhoPhi,U) Gauss limitedLinearV 1;
div(phi,U) Gauss limitedLinearV 1;
div(alphaRhoPhi,e) Gauss limitedLinear 1;
div(alphaRhoPhi,K) Gauss limitedLinear 1;
div(alphaRhoPhi,(p|rho)) Gauss limitedLinear 1;
div((((alpha*rho)*nuEff)*dev2(T(grad(U))))) Gauss linear;
}
rather than using complex regular expressions as done previously:
divSchemes
{
default none;
div(phi,alpha.air) Gauss vanLeer;
div(phi,alpha.water) Gauss vanLeer;
div(phir,alpha.water,alpha.air) Gauss vanLeer;
div(phir,alpha.air,alpha.water) Gauss vanLeer;
"div\(alphaRhoPhi.*,U.*\)" Gauss limitedLinearV 1;
"div\(phi.*,U.*\)" Gauss limitedLinearV 1;
"div\(alphaRhoPhi.*,(h|e).*\)" Gauss limitedLinear 1;
"div\(alphaRhoPhi.*,K.*\)" Gauss limitedLinear 1;
"div\(alphaRhoPhi.*,\(p\|rho.*\)\)" Gauss limitedLinear 1;
"div\(alphaRhoPhi.*,\(p\|rho.*\)\)" Gauss limitedLinear 1;
"div\(\(\(\(alpha.*\*rho.*\)*nuEff.*\)\*dev2\(T\(grad\(U.*\)\)\)\)\)" Gauss linear;
}
Now that thermal transport is implemented as an energy implicit correction on an
explicit temperature gradient formulation it is more efficient if the implicit
correction contains only the implicit terms of the matrix and not the explicit
non-orthogonal or anisotropic correction terms which are cancelled anyway when
the evaluation of the matrix for the current state is subtracted. The new
fvm::laplacianCorrection functions provide a convenient mechanism to efficiently
evaluate only the implicit correction to the laplacian and is now used in all
the thermophysicalTransportModels.
Now that kappa, Cp and Cv fields are cached and Cpv returns either the Cp or Cv
field reference depending on the energy solved and thermal transport is now
fundamentally based on temperature rather energy gradients it is no longer
necessary or useful to provide an abstract function returning alphahe.
This renaming only occurs for single-phase compressible solvers instantiating a
rhoThermo, e.g. for liquids, and usually the rhoThermo:rho is not looked-up by
sub-models or boundary conditions and if needed is better obtained from the
thermo package directly.
The thermodynamic density field is now named "rho" by default and only renamed
"thermo:rho" by solvers that create and maintain a separate continuity density
field which is named "rho". This change significantly simplifies and
standardises the specification of schemes and boundary conditions requiring
density as it is now always named "rho" or "rho.<phase>" unless under some very
unusual circumstances the thermodynamic rather than continuity density is
required for a solver maintaining both.
The advantage of this change is particularly noticeable for multiphase
simulations in which each phase has its own density now named "rho.<phase>"
rather than "thermo:rho.<phase>" as separate phase continuity density fields are
not required so for multiphaseEulerFoam the scheme specification:
"div\(alphaRhoPhi.*,\(p\|thermo:rho.*\)\)" Gauss limitedLinear 1;
is now written:
"div\(alphaRhoPhi.*,\(p\|rho.*\)\)" Gauss limitedLinear 1;
The basic thermophysical properties are now considered fundamental and complex
models like kineticTheoryModel using these names for some other purpose must
disambiguate using typedName to prepend the model name to the field name.
This change standardises, rationalises and simplifies the specification of
fvSchemes and boundary conditions.
thermo:rho will also be renamed rho in a subsequent commit to complete this
rationalisation.
Description
Uniform or non-uniform constant solid thermodynamic properties
Each physical property can specified as either \c uniform in which case the
value entry is read or \c file in which case the field file in read
from the constant directory.
Usage
Example of uniform constant solid properties specification:
\verbatim
thermoType constSolidThermo;
rho
{
type uniform;
value 8940;
}
Cv
{
type uniform;
value 385;
}
kappa
{
type uniform;
value 380;
}
\endverbatim
Example of non-uniform constant solid properties specification:
\verbatim
thermoType constSolidThermo;
rho
{
type file;
}
Cv
{
type file;
}
kappa
{
type file;
}
\endverbatim
where each of the field files are read from the constant directory.
to handle the wall heat-flux generated by the tangential components of the
temperature gradient when the thermal conductivity tensor Kappa does not align
with the boundary. This is an uncommon situation but for cases where it is
important it must be handled correctly; previously this term was ignored.
For efficiency the temperature gradient field is automatically cached so that it
is not evaluated for every patch for which Kappa is not aligned with the
boundary, and the correction is evaluated and applied only for those patches.
The heat-flux correction qCorr is used in the coupled and external heat-flux
boundary conditions coupledTemperature and externalTemperature.
the new fluidThermophysicalTransportModel and solidThermophysicalTransportModel
are derived from thermophysicalTransportModel providing a consistent and unified
interface for heat transport within and between regions. Coupled and external
heat-transfer boundary conditions can now be written independent of the
thermophysical properties or transport modelling of the regions providing
greater flexibility, simpler code and reduces the maintenance overhead.
The previous fluidThermophysicalTransportModel typedef has been renamed
fluidThermoThermophysicalTransportModel as it is instantiated on fluidThermo,
freeing the name fluidThermophysicalTransportModel for the new base-class.
so that derived classes can call the dictionary constructor without reading the
refValue, refGradient or valueFraction entries. This ensures that the
fvPatchField dictionary constructor is called, setting optional entries like
'libs' as required.
