The phase velocity mean adjustment was introduced for consistency with phase
flux mean adjustment which is necessary to ensure the mean flux divergence is
preserved. However for systems with very high drag it has proved preferable to
not adjust the velocity of the phases to conserve momentum rather than ensure
consistency with the fluxes.
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.
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.
at Function1s of time.
Underlying this new functionObject is a generalisation of the handling of the
maximum time-step in the modular solvers to allow complex user-specification of
the maximum time-step used in a simulation, not just the time-dependency
provided by fluidMaxDeltaT but functions of anything in the simulation by
creating a specialised functionObject in which the maxDeltaT function is
defined.
The chemical and combustion time-scale functionObjects adjustTimeStepToChemistry
and adjustTimeStepToCombustion have been updated and simplified using the above
mechanism.
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.
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.
setFormat no longer defaults to the value of graphFormat optionally set in
controlDict and must be set in the functionObject dictionary.
boundaryFoam, financialFoam and pdfPlot still require a graphFormat entry in
controlDict but this is now read directly rather than by Time.
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;
}
The velocity boundary conditions are corrected before the construction of the
face velocity or momentum but for multi-region cases with interacting velocity
boundary conditions this is only possible after all the region solver modules
have been constructed so it is better to delay the optional construction of the
face velocity/momentum until preSolve().
This avoids potential hidden run-time errors caused by solvers running with
boundary conditions which are not fully specified. Note that "null-constructor"
here means the constructor from patch and internal field only, no data is
provided.
Constraint and simple BCs such as 'calculated', 'zeroGradient' and others which
do not require user input to fully specify their operation remain on the
null-constructor table for the construction of fields with for example all
'calculated' or all 'zeroGradient' BCs.
A special version of the 'inletOutlet' fvPatchField named 'zeroInletOutlet' has
been added in which the inlet value is hard-coded to zero which allows this BC
to be included on the null-constructor table. This is useful for the 'age'
functionObject to avoid the need to provide the 'age' volScalarField at time 0
unless special inlet or outlet BCs are required. Also for isothermalFilm in
which the 'alpha' field is created automatically from the 'delta' field if it is
not present and can inherit 'zeroInletOutlet' from 'delta' if appropriate. If a
specific 'inletValue' is require or other more complex BCs then the 'alpha'
field file must be provided to specify these BCs as before.
Following this improvement it will now be possible to remove the
null-constructors from all fvPatchFields not added to the null-constructor
table, which is most of them, thus reducing the amount of code and maintenance
overhead and making easier and more obvious to write new fvPatchField types.
