Description
Uniform or non-uniform constant anisotropic solid thermodynamic properties
Each physical property can specified as either \c uniform in which case the
value entry is read, \c zonal in which case the value entry and zone list
are read or \c file in which case the field file in read from the constant
directory. The thermal conductivity \c Kappa is anisotropic and read as a
diagonal tensor or diagonal tensor field provided in the form of a vector
or vector field.
Usage
Example of uniform constant solid properties specification:
\verbatim
thermoType constAnisoSolidThermo;
rho
{
type uniform;
value 8940;
}
Cv
{
type uniform;
value 385;
}
Kappa
{
type uniform;
value (380 100 100);
}
\endverbatim
Example of zonal constant solid properties specification where Kappa is
different in different zones:
\verbatim
thermoType constSolidThermo;
rho
{
type uniform;
value 8940;
}
Cv
{
type uniform;
value 385;
}
Kappa
{
type zonal;
value (380 380 380);
zones
{
heater (560 560 560);
insulation (10 100 100);
}
}
\endverbatim
Example of non-uniform constant solid properties specification:
\verbatim
thermoType constAnisoSolidThermo;
rho
{
type file;
}
Cv
{
type file;
}
Kappa
{
type file;
}
\endverbatim
where each of the field files are read from the constant directory.
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, \c zonal in which case the value entry and zone list
are 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 zonal constant solid properties specification where kappa is
different in different zones:
\verbatim
thermoType constSolidThermo;
rho
{
type uniform;
value 8940;
}
Cv
{
type uniform;
value 385;
}
kappa
{
type zonal;
value 380;
zones
{
heater 560;
insulation 100;
}
}
\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.
Three functions for generating fluxes of the Lagrangian parcels have
been added. These are 'numberFlux', 'volumeFlux' and 'massFlux'. They
require only the type specifying; no further controls are needed. If it
is desired only to generate and register the field, and not write it,
then a 'write no;' setting can be applied.
For example, in constant/cloudProperties:
cloudFunctions
{
massFlux1
{
type massFlux; // numberFlux, volumeFlux, or massFlux
write no;
}
}
The 'postFace' hook is now called at the start of a tracking step, if
the particle is on a face. Execution is therefore reliably *after* an
interaction with a face. There is a new 'preFace' hook which is called
at the end of tracking; i.e., *before* an interaction with a face. The
'postPatch' hook is unchanged, but it is triggered more carefully so
that it does actually execute *after* the patch interaction.
This fixes a number of issues associated with interaction with
constraint and coupled patches. It also allows for functions to be
defined that have dependence on the direction (relative to the face
normal) in which a particle-face interaction takes place.
The localInteraction model now no longer requires specification of an
interaction on any constrained patch type (e.g., symmetry, cyclic, ...).
Non-constrained types (patch, wall, ...) require an interaction to be
specified as before and will trigger an error if this is not the case.
In addition, constrained patches can be overridden by providing a
'patchType' specifier, in the same way as would be done to override a
constrained boundary condition for finite volume.
The filter tutorial now correctly demonstrates something unique; i.e.,
particles rebounding from a cyclic. It has therefore been reinstated.
Resolves (properly) bug report https://bugs.openfoam.org/view.php?id=3923
Description
Writes the position, linear and angular velocities and accelerations of a
list of points on a body specified in the body local coordinate system.
Usage
\table
Property | Description | Required | Default value
type | type name: rigidBodyPoints | yes |
angleUnits | degrees or radians | no | radians
body | name of the body | yes |
points | list of points on the body | yes |
\endtable
Example of function object specification:
\verbatim
rigidBodyPoints
{
type rigidBodyPoints;
libs ("librigidBodyState.so");
angleUnits degrees;
body floatingObject;
points
(
point1 (0 0 0)
point2 (0.1 0.1 0.25)
);
}
\endverbatim
A set of routines for cutting polyhedra have been added. These can cut
polyhedral cells based on the adjacent point values and an iso-value
which defines the surface. The method operates directly on the
polyhedral cells; it does not decompose them into tetrahedra at any
point. The routines can compute the cut topology as well as integrals of
properties above and below the cut surface.
An iso-surface algorithm has been added based on these polyhedral
cutting routines. It is significantly more robust than the previous
algorithm, and produces compact surfaces equivalent to the previous
algorithm's maximum filtering level. It is also approximately 3 times
faster than the previous algorithm, and 10 times faster when run
repeatedly on the same set of cells (this is because some addressing is
cached and reused).
This algorithm is used by the 'isoSurface', 'distanceSurface' and
'cutPlane' sampled surfaces.
The 'cutPlane' sampled surface is a renaming of 'cuttingPlane' to make
it consistent with the corresponding packaged function. The name
'cuttingPlane' has been retained for backwards compatibility and can
still be used to select a 'cutPlane' surface. The legacy 'plane' surface
has been removed.
The 'average' keyword has been removed from specification of these
sampled surfaces as cell-centred values are no longer used in the
generation of or interpolation to an iso-surface. The 'filtering'
keyword has also been removed as it relates to options within the
previous algorithm. Zone support has been reinstated into the
'isoSurface' sampled surface. Interpolation to all these sampled
surfaces has been corrected to exactly match the user-selected
interpolation scheme, and the interpolation procedure no longer
unnecessarily re-generates data that is already available.
which can be selected and executed in foamMultiRun for complex CHT cases. This
is a much more general, flexible, extensible and maintainable structure than the
now deprecated regionModels system and associated clutter.
Now fluxes are updated from the mapped fields following mesh topology change
with or without implicit continuity correction enabled by the optional
correctPhi switch.
Given that the number of solid solver modules is currently 1 and unlikely to
exceed 3 it is not very useful to maintain solid and fluid sub-directories and
easier to see the correspondence between the solver modules and tutorial cases
without.
This serves as an example of cavitation modelling with the
multiphaseEuler module. This case also contains validation of the
pressure profile along the hydrofoil against experimental data.
Based on a case contributed by Petteri Peltonen, VTT.
This adds cavitation modelling to the multiphaseEuler solver module as a
phaseTransfer model. The underlying cavitation modelling is the same as
for the compressibleVoF module.
An example specification in constant/phaseProperties is shown below:
phaseTransfer
{
gas_liquid
{
type cavitation;
model Kunz;
liquid water;
pSat 80000;
UInf 5.33;
tInf 0.028142589;
Cc 100;
Cv 100;
}
}
Based on code contributed by Petteri Peltonen, VTT.
The cavitation models used by the compressibleVoF module can now have a
temperature-dependent saturation pressure model specified. For example,
in the constant/fvModels file of a compressibleVoF case:
VoFCavitation
{
type VoFCavitation;
libs ("libcompressibleVoFCavitation.so");
model SchnerrSauer;
liquid water;
// Constant saturation pressure
//pSat 2300;
// Antoine equation for temperature-dependent saturation pressure
pSat
{
type Antoine;
A 22;
B -3000;
C -500;
}
n 1.6e+13;
dNuc 2.0e-06;
Cc 1;
Cv 1;
}
The cavitation models used by the interFoam solver and the
compressibleVoF solver module can now be applied regardless of the
ordering of the liquid and vapour phases. A "liquid" keyword is now
required in the model specification in order to control which phase is
considered to be the condensed liquid state. Previously the liquid phase
was assumed to be the first of the two phases.
The multiphaseEuler module now uses saturation models from the
centralised thermophysical properties library.
The control of these models is slightly different than for the previous
multiphaseEuler-specific saturation models. Where previously a
"saturationPressure" or "saturationTemperature" sub-dictionary was
employed, now "pSat" and "Tsat" entries are used which can be specified
flexibly in a similar manner to function1-s. See the previous commit for
details.
These models are intended to provide saturation curves for use in
multiple solvers and sub-models. They can be specified in a similar
manner to function1-s in that value, type or sub-dictionary entries are
all supported. The following specifications for a constant saturation
pressure are all equivalent:
// Value specified. Creates "constant" model.
pSat 8000;
// Type specified. Coefficients provided in the same dictionary.
pSat constant;
value 8000;
// Type specified. Coefficients provided in a coeffs dictionary.
pSat constant;
pSatCoeffs
{
value 8000;
}
// Sub-dictionary specification.
pSat
{
type constant;
value 8000;
}
Supersedes and replaces the tutorials/modules/multiphaseEuler/wallBoiling case
as it is more physical and representative of a real case.
Patch contributed by Juho Peltola, VTT.
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.
