for the multiphaseEuler solver module, replacing the more specific
uniformFixedMultiphaseHeatFluxFvPatchScalarField as it provide equivalent
functionality if the heat-flux q is specified.
multiphaseExternalTemperatureFvPatchScalarField is derived from the refactored
and generalised externalTemperatureFvPatchScalarField, overriding the
getKappa member function to provide the multiphase equivalents of kappa and
other heat transfer properties. All controls for
multiphaseExternalTemperatureFvPatchScalarField are the same as for
externalTemperatureFvPatchScalarField:
Class
Foam::externalTemperatureFvPatchScalarField
Description
This boundary condition applies a heat flux condition to temperature
on an external wall. Heat flux can be specified in the following ways:
- Fixed power: requires \c Q
- Fixed heat flux: requires \c q
- Fixed heat transfer coefficient: requires \c h and \c Ta
where:
\vartable
Q | Power Function1 of time [W]
q | Heat flux Function1 of time [W/m^2]
h | Heat transfer coefficient Function1 of time [W/m^2/K]
Ta | Ambient temperature Function1 of time [K]
\endvartable
Only one of \c Q or \c q may be specified, if \c h and \c Ta are also
specified the corresponding heat-flux is added.
If the heat transfer coefficient \c h is specified an optional thin thermal
layer resistances can also be specified through thicknessLayers and
kappaLayers entries.
The patch thermal conductivity \c kappa is obtained from the region
thermophysicalTransportModel so that this boundary condition can be applied
directly to either fluid or solid regions.
Usage
\table
Property | Description | Required | Default value
Q | Power [W] | no |
q | Heat flux [W/m^2] | no |
h | Heat transfer coefficient [W/m^2/K] | no |
Ta | Ambient temperature [K] | if h is given |
thicknessLayers | Layer thicknesses [m] | no |
kappaLayers | Layer thermal conductivities [W/m/K] | no |
relaxation | Relaxation for the wall temperature | no | 1
emissivity | Surface emissivity for radiative flux to ambient | no | 0
qr | Name of the radiative field | no | none
qrRelaxation | Relaxation factor for radiative field | no | 1
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type externalTemperature;
Ta constant 300.0;
h uniform 10.0;
thicknessLayers (0.1 0.2 0.3 0.4);
kappaLayers (1 2 3 4);
value $internalField;
}
\endverbatim
See also
Foam::mixedFvPatchScalarField
Foam::Function1
The mappedValueFvPatchField boundary condition is special in that it can
construct its own mapping information if none is provided by the
underlying patch. This means different fields can be mapped between the
same patches with different mapping strategies. It is quite flexible,
and is often used for recyling properties between boundaries in order to
fully develop their profiles. It provides the ability to set the mean
and similar in order to facilitate this sort of usage.
It is not intended to be used in situations in which patches are
physically connected; region interfaces and similar. These connections
are required to be defined in the underlying patches themselves, as they
relate more fundamentally to the configuration of the mesh rather than
just the boundary conditions of specific fields.
Boundary conditions that map across physical connections (e.g.,
coupledTemperature, mappedFilmPressure, ...) are therefore required to
apply to a mapped patch. The mapping in these situations is a property
of the mesh, not of the boundary condition. If these conditions are
applied to a non-mapped patch then they will fail.
This change formalises the above logic and removes a now unnecessary
base class which was previously being used to share
mappedValueFvPatchField's mapping construction behaviour with other
boundary conditions.
The mappedValueAndPatchInternalValue condition has also been removed, as
this was only previously used in film, and has been replaced by simpler
and more usable options.
including blockMeshDict, surfaceFeaturesDict and snappyHexMeshDict, based on the
case surface geometry.
Description
Preconfigures blockMeshDict, surfaceFeaturesDict and snappyHexMeshDict
files based on the case surface geometry files.
Starting from a standard OpenFOAM case, this utility locates surface
geometry files, e.g. OBJ, STL format, in the constant/geometry directory.
It writes out the configuration files for mesh generation with
snappyHexMesh based on assumptions which can be overridden by options on
the command line.
The utility processes the surface geometry files, attempting to anticipate
their intended purpose, trying in particular to recognise whether the
domain represents an external or internal flow. If there is a surface
which is closed, and is either single or surrounds all other surfaces,
then it is assumed that it forms the external boundary of an internal
flow. This assumption is overridden if the bounds of the background mesh
are specified using the '-bounds' option and they are more than 50% larger
than the surface bounds.
Surfaces which form boundaries of the domain may contain named regions
that are intended to become patches in the final mesh. Any surface region
whose name begins with 'inlet' or 'outlet' will become a patch of the same
name in the final mesh. On an external surface (for an internal flow),
regions can be identified as inlets and outlets using the '-inletRegions'
and '-outletRegions' options, respectively. When either option specifies a
single region, the resulting patch name will be specifically 'inlet' or
'outlet', respectively. Surfaces which are contained within the domain,
which do not surround or intersect other surfaces, are assumed by default
to be wall patches. Any closed surface which surrounds another (but not an
external surface) is used to form a cellZone within the mesh. Any surface
can be specifically identified as a cellZone with the '-cellZones' option,
with the additional '-baffles' and '-rotatingZones' options available to
assign a surface to a more specific use.
The background mesh for snappyHexMesh is a single block generated by
blockMesh, configured using a blockMeshDict file. The block bounds are
automatically calculated, but can be overridden by the '-bounds'
option. The number of cells is calculated to produce a fairly small
prototype mesh. The cell density can be overridden by the '-nCells' option
or can be scaled up by an integer factor using the '-refineBackground'
option. When the background mesh is required to form patches in the final
mesh, e.g. for an external flow, the user can specify the names and types
of the patches corresponding to the six block faces using options such as
'-xMinPatch', '-xMaxPatch', etc. The name and type of the default patch,
formed from block faces which are not configured, can also be specified
with the '-defaultPatch' option. The utility provides placeholder entries
for all block faces unless the '-clearBoundary' option is used. A special
'-cylindricalBackground' option generates a cylindrical background mesh,
oriented along the z-axis along x = y = 0.
The snappyHexMesh configuration is generated automatically, applying a set
of defaults to the main configuration parameters. By default, explicit
feature capturing is configured, for which a surfaceFeaturesDict file is
written for the user to generate the features files with the
surfaceFeatures utility. Implicit feature capturing can alternatively be
selected with the '-implicitFeatures' option. Refinement levels can be
controlled with a range of options including: '-refinementLevel' for the
baseline refinement level; '-refinementSurfaces' for levels on specific
surfaces; '-refinementRegions' for levels inside specific surfaces;
'-refinementBoxes' for quick, box-shaped refinement regions specified by
min and max bounds; '-refinementDists' for distance-based refinement; and
'-nCellsBetweenLevels' to control the transition between refinement
levels. A '-layers' option specifies additional layers of cells at wall
boundaries. The insidePoint parameter is set to '(0 0 0)' by default but
can be overridden using the '-insidePoint' option.
If the code string is delimited by '#{...#}' multiple lines and multiple code
statements can be used to generate the entry using 'os << ...;'. This is
equivalent to #codeStream but with a more compact syntax, e.g.
maxAngle 30;
nAngles 7;
Us #calc
const vector U($<vector>testCalc2!U);
const int nAngles = $nAngles;
const scalar angleStep = ($<scalar>maxAngle)/(nAngles - 1);
List<vector> Us(nAngles);
for(int i=0; i<nAngles; i++)
{
const scalar angle = degToRad(i*angleStep);
Us[i] = transform(Ry(angle), U);
}
os << Us;
Note the 'os << Us;' statement which writes the data to the dictionary entry in
the same manner as #codeStream, this provides flexibility on how the data is
created and written.
This allows #FOAM_CASE for example to be used in #calc variable lookup, e.g. in
test/dictionary/testCalc:
// assuming the testCalc2 file is local
magU #calc "mag($<vector>testCalc2!U)";
// finding the testCalc2 file using $FOAM_CASE
k #calc "1.5*magSqr(0.05*$<vector>{${FOAM_CASE}/testCalc2!U})";
This provides a smooth solution but it is not clear if this is more accurate
than running the cellMomentum p-U algorithm which generates complex transients
in the solution.
