terms of the local barycentric coordinates of the current tetrahedron,
rather than the global coordinate system.
Barycentric tracking works on any mesh, irrespective of mesh quality.
Particles do not get "lost", and tracking does not require ad-hoc
"corrections" or "rescues" to function robustly, because the calculation
of particle-face intersections is unambiguous and reproducible, even at
small angles of incidence.
Each particle position is defined by topology (i.e. the decomposed tet
cell it is in) and geometry (i.e. where it is in the cell). No search
operations are needed on restart or reconstruct, unlike when particle
positions are stored in the global coordinate system.
The particle positions file now contains particles' local coordinates
and topology, rather than the global coordinates and cell. This change
to the output format is not backwards compatible. Existing cases with
Lagrangian data will not restart, but they will still run from time
zero without any modification. This change was necessary in order to
guarantee that the loaded particle is valid, and therefore
fundamentally prevent "loss" and "search-failure" type bugs (e.g.,
2517, 2442, 2286, 1836, 1461, 1341, 1097).
The tracking functions have also been converted to function in terms
of displacement, rather than end position. This helps remove floating
point error issues, particularly towards the end of a tracking step.
Wall bounded streamlines have been removed. The implementation proved
incompatible with the new tracking algorithm. ParaView has a surface
LIC plugin which provides equivalent, or better, functionality.
Additionally, bug report <https://bugs.openfoam.org/view.php?id=2517>
is resolved by this change.
By specifying the optional outside surface emissivity radiative heat transfer to
the ambient conditions is enabled. The far-field is assumed to have an
emissivity of 1 but this could be made an optional input in the future if
needed.
Relaxation of the surface temperature is now provided via the optional
"relaxation" which aids stability of steady-state runs with strong radiative
coupling to the boundary.
except turbulence and lagrangian which will also be updated shortly.
For example in the nonNewtonianIcoFoam offsetCylinder tutorial the viscosity
model coefficients may be specified in the corresponding "<type>Coeffs"
sub-dictionary:
transportModel CrossPowerLaw;
CrossPowerLawCoeffs
{
nu0 [0 2 -1 0 0 0 0] 0.01;
nuInf [0 2 -1 0 0 0 0] 10;
m [0 0 1 0 0 0 0] 0.4;
n [0 0 0 0 0 0 0] 3;
}
BirdCarreauCoeffs
{
nu0 [0 2 -1 0 0 0 0] 1e-06;
nuInf [0 2 -1 0 0 0 0] 1e-06;
k [0 0 1 0 0 0 0] 0;
n [0 0 0 0 0 0 0] 1;
}
which allows a quick change between models, or using the simpler
transportModel CrossPowerLaw;
nu0 [0 2 -1 0 0 0 0] 0.01;
nuInf [0 2 -1 0 0 0 0] 10;
m [0 0 1 0 0 0 0] 0.4;
n [0 0 0 0 0 0 0] 3;
if quick switching between models is not required.
To support this more convenient parameter specification the inconsistent
specification of seedSampleSet in the streamLine and wallBoundedStreamLine
functionObjects had to be corrected from
// Seeding method.
seedSampleSet uniform; //cloud; //triSurfaceMeshPointSet;
uniformCoeffs
{
type uniform;
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
to the simpler
// Seeding method.
seedSampleSet
{
type uniform;
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
which also support the "<type>Coeffs" form
// Seeding method.
seedSampleSet
{
type uniform;
uniformCoeffs
{
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
}
Radiative heat transfer may now be added to any solver in which an energy
equation is solved at run-time rather than having to change the solver code.
For example, radiative heat transfer is now enabled in the SandiaD_LTS
reactingFoam tutorial by providing a constant/fvOptions file containing
radiation
{
type radiation;
libs ("libradiationModels.so");
}
and appropriate settings in the constant/radiationProperties file.
For example the porosity coefficients may now be specified thus:
porosity1
{
type DarcyForchheimer;
cellZone porosity;
d (5e7 -1000 -1000);
f (0 0 0);
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type axesRotation;
e1 (0.70710678 0.70710678 0);
e2 (0 0 1);
}
}
}
rather than
porosity1
{
type DarcyForchheimer;
active yes;
cellZone porosity;
DarcyForchheimerCoeffs
{
d (5e7 -1000 -1000);
f (0 0 0);
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type axesRotation;
e1 (0.70710678 0.70710678 0);
e2 (0 0 1);
}
}
}
}
support for which is maintained for backward compatibility.
For example the actuationDiskSource fvOption may now be specified
disk1
{
type actuationDiskSource;
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
rather than
disk1
{
type actuationDiskSource;
active on;
actuationDiskSourceCoeffs
{
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
}
but this form is supported for backward compatibility.
Main changes in the tutorial:
- General cleanup of the phaseProperties of unnecessary entries
- sensibleEnthalpy is used for both phases
- setTimeStep functionObject is used to set a sharp reduction in time step near the start of the injection
- Monitoring of pressure minimum and maximum
Patch contributed by Juho Peltola, VTT.
The standard naming convention for heat flux is "q" and this is used for the
conductive and convective heat fluxes is OpenFOAM. The use of "Qr" for
radiative heat flux is an anomaly which causes confusion, particularly for
boundary conditions in which "Q" is used to denote power in Watts. The name of
the radiative heat flux has now been corrected to "qr" and all models, boundary
conditions and tutorials updated.
by combining with and rationalizing functionality from
turbulentHeatFluxTemperatureFvPatchScalarField.
externalWallHeatFluxTemperatureFvPatchScalarField now replaces
turbulentHeatFluxTemperatureFvPatchScalarField which is no longer needed and has
been removed.
Description
This boundary condition applies a heat flux condition to temperature
on an external wall in one of three modes:
- fixed power: supply Q
- fixed heat flux: supply q
- fixed heat transfer coefficient: supply h and Ta
where:
\vartable
Q | Power [W]
q | Heat flux [W/m^2]
h | Heat transfer coefficient [W/m^2/K]
Ta | Ambient temperature [K]
\endvartable
For heat transfer coefficient mode optional thin thermal layer resistances
can be specified through thicknessLayers and kappaLayers entries.
The thermal conductivity \c kappa can either be retrieved from various
possible sources, as detailed in the class temperatureCoupledBase.
Usage
\table
Property | Description | Required | Default value
mode | 'power', 'flux' or 'coefficient' | yes |
Q | Power [W] | for mode 'power' |
q | Heat flux [W/m^2] | for mode 'flux' |
h | Heat transfer coefficient [W/m^2/K] | for mode 'coefficent' |
Ta | Ambient temperature [K] | for mode 'coefficient' |
thicknessLayers | Layer thicknesses [m] | no |
kappaLayers | Layer thermal conductivities [W/m/K] | no |
qr | Name of the radiative field | no | none
qrRelaxation | Relaxation factor for radiative field | no | 1
kappaMethod | Inherited from temperatureCoupledBase | inherited |
kappa | Inherited from temperatureCoupledBase | inherited |
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type externalWallHeatFluxTemperature;
mode coefficient;
Ta uniform 300.0;
h uniform 10.0;
thicknessLayers (0.1 0.2 0.3 0.4);
kappaLayers (1 2 3 4);
kappaMethod fluidThermo;
value $internalField;
}
\endverbatim
Description
Temperature-dependent surface tension model in which the surface tension
function provided by the phase Foam::liquidProperties class is used.
Usage
\table
Property | Description | Required | Default value
phase | Phase name | yes |
\endtable
Example of the surface tension specification:
\verbatim
sigma
{
type liquidProperties;
phase water;
}
\endverbatim
for use with e.g. compressibleInterFoam, see
tutorials/multiphase/compressibleInterFoam/laminar/depthCharge2D
snappyHexMesh produces a far better quality AMI interface using a cylindrical background mesh,
leading to much more robust performance, even on a relatively coarse mesh. The min/max AMI
weights remain close to 1 as the mesh moves, giving better conservation.
The rotating geometry template cases are configured with a blockMeshDict file for a cylindrical
background mesh aligned along the z-axis. The details of use are found in the README and
blockMeshDict files.
Uncommenting the patches provides a convenient way to use the patches in the background mesh
to define the external boundary of the final mesh. Replaces previous setup with a separate
blockMeshDict.extPatches file.
These models have been particularly designed for use in the VoF solvers, both
incompressible and compressible. Currently constant and temperature dependent
surface tension models are provided but it easy to write models in which the
surface tension is evaluated from any fields held by the mesh database.
Created a base-class from contactAngleForce from which the
distributionContactAngleForce (for backward compatibility) and the new
temperatureDependentContactAngleForce are derived:
Description
Temperature dependent contact angle force
The contact angle in degrees is specified as a \c Function1 type, to
enable the use of, e.g. contant, polynomial, table values.
See also
Foam::regionModels::surfaceFilmModels::contactAngleForce
Foam::Function1Types
SourceFiles
temperatureDependentContactAngleForce.C
Demonstrates meshing a cylinder with hemispehrical ends using snappyHexMesh with
a polar background mesh that uses the point and edge projection feature of blockMesh.
The case prescribes a multiMotion on the cylinder, combining an oscillatingLinearMotion
and transverse rotatingMotion.
