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.
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.
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.
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.
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.
Renamed classes:
turbulentTemperatureCoupledBaffleMixedFvPatchScalarField ->
coupledTemperatureFvPatchScalarField
externalWallHeatFluxTemperatureFvPatchScalarField ->
externalTemperatureFvPatchScalarField
Radiation heat-flux support in turbulentTemperatureRadCoupledMixed transferred
to coupledTemperatureFvPatchScalarField and turbulentTemperatureRadCoupledMixed removed.
Renamed boundary condition type names in T field files:
compressible::turbulentTemperatureCoupledBaffleMixed -> coupledTemperature
compressible::turbulentTemperatureRadCoupledMixed -> coupledTemperature
compressible::externalWallHeatFluxTemperature -> externalTemperature
Backward-compatibility is provided for all three of the above BC specifications
so existing cases will run as before but we recommend migrating to the new
simpler names.
The mappedPatchBase has been separated into a type which maps from
another patch (still called mappedPatchBase) and one that maps from
internal cell values (mappedInternalPatchBase). This prevents the user
needing to specify settings for mapping procedures that are not being
used, and potentially don't even make sense given the context in which
they are being applied. It also removes a lot of fragile logic and error
states in the mapping engine and its derivatives regarding the mode of
operation. Mapping from any face in the boundary is no longer supported.
Most region-coupling mapping patches are generated automatically by
utilities like splitMeshRegions and extrudeToRegionMesh. Cases which
create region-coupling mapped patches in this way will likely require no
modification.
Explicitly user-specified mapping will need modifying, however. For
example, where an inlet boundary is mapped to a downstream position in
order to evolve a developed profile. Or if a multi-region simulation is
constructed manually, without using one of the region-generating
utilities.
The available mapped patch types are now as follows:
- mapped: Maps values from one patch to another. Typically used for
inlets and outlets; to map values from an outlet patch to an inlet
patch in order to evolve a developed inlet profile, or to permit
flow between regions. Example specification in blockMesh:
inlet
{
type mapped;
neighbourRegion region0; // Optional. Defaults to the same
// region as the patch.
neighbourPatch outlet;
faces ( ... );
}
Note that any transformation between the patches is now determined
automatically. Alternatively, it can be explicitly specified using
the same syntax as for cyclic patches. The "offset" and "distance"
keywords are no longer used.
- mappedWall: As mapped, but treated as a wall for the purposes of
modelling (wall distance). No transformation. Typically used for
thermally coupling different regions. Usually created automatically
by meshing utilities. Example:
fluid_to_solid
{
type mappedWall;
neighbourRegion solid;
neighbourPatch solid_to_fluid;
method intersection; // The patchToPatch method. See
// below.
faces ( ... );
}
- mappedExtrudedWall: As mapped wall, but with corrections to account
for the thickness of an extruded mesh. Used for region coupling
involving film and thermal baffle models. Almost always generated
automatically by extrudeToRegionMesh (so no example given).
- mappedInternal: Map values from internal cells to a patch. Typically
used for inlets; to map values from internal cells to the inlet in
order to evolve a developed inlet profile. Example:
inlet
{
type mappedInternal;
distance 0.05; // Normal distance from the patch
// from which to map cell values
//offset (0.05 0 0); // Offset from the patch from
// which to map cell values
faces ( ... );
}
Note that an "offsetMode" entry is no longer necessary. The mode
will be inferred from the presence of the distance or offset
entries. If both are provided, then offsetMode will also be required
to choose which setting applies.
The mapped, mappedWall and mappedExtrudedWall patches now permit
specification of a "method". This selects a patchToPatch object and
therefore determines how values are transferred or interpolated between
the patches. Valid options are:
- nearest: Copy the value from the nearest face in the neighbouring
patch.
- matching: As nearest, but with checking to make sure that the
mapping is one-to-one. This is appropriate for patches that are
identically meshed.
- inverseDistance: Inverse distance weighting from a small stencil of
nearby faces in the neighbouring patch.
- intersection: Weighting based on the overlapping areas with faces in
the neighbouring patch. Equivalent to the previous AMI-based mapping
mode.
If a method is not specfied, then the pre-existing approach will apply.
This should be equivalent to the "nearest" method (though in most such
cases, "matching" is probably more appropriate). This fallback may be
removed in the future once the patchToPatch methods have been proven
robust.
The important mapped boundary conditions are now as follows:
- mappedValue: Maps values from one patch to another, and optionally
modify the mapped values to recover a specified average. Example:
inlet
{
type mappedValue;
field U; // Optional. Defaults to the same
// as this field.
average (10 0 0); // The presence of this entry now
// enables setting of the average,
// so "setAverage" is not needed
value uniform 0.1;
}
- mappedInternalValue: Map values from cells to a patch, and
optionally specify the average as in mappedValue. Example:
inlet
{
type mappedValue;
field k; // Optional. Defaults to the same
// as this field.
interpolationScheme cell;
value uniform 0.1;
}
- mappedFlowRateVelocity: Maps the flow rate from one patch to
another, and use this to set a patch-normal velocity. Example:
inlet
{
type mappedFlowRate;
value uniform (0 0 0);
}
Of these, mappedValue and mappedInternalValue can override the
underlying mapped patch's settings by additionally specifying mapping
information (i.e., the neighbourPatch, offset, etc... settings usually
supplied for the patch). This also means these boundary condtions can be
applied to non-mapped patches. This functionality used to be provided
with a separate "mappedField" boundary condition, which has been removed
as it is no longer necessary.
Other mapped boundary conditions are either extremely niche (e.g.,
mappedVelocityFlux), are always automatically generated (e.g.,
mappedValueAndPatchInternalValue), or their usage has not changed (e.g.,
compressible::turbulentTemperatureCoupledBaffleMixed and
compressible::turbulentTemperatureRadCoupledMixed). Use foamInfo to
obtain further details about these conditions.
This greatly simplifies most setups in which it is a patch (or patches)
of the original mesh which are extruded. It prevents the need for a
topoSet configuration to convert the patch into a zone or set.
This is a better way of doing 3D thermal baffles. It does not require a
special region model and is consistent with multi-region handling in
other parts of OpenFOAM.
Description
General cell set selection class for models that apply to sub-sets
of the mesh.
Currently supports cell selection from a set of points, a specified cellSet
or cellZone or all of the cells. The selection method can either be
specified explicitly using the \c selectionMode entry or inferred from the
presence of either a \c cellSet, \c cellZone or \c points entry. The \c
selectionMode entry is required to select \c all cells.
Usage
Examples:
\verbatim
// Apply everywhere
selectionMode all;
// Apply within a given cellSet
selectionMode cellSet; // Optional
cellSet rotor;
// Apply within a given cellZone
selectionMode cellZone; // Optional
cellSet rotor;
// Apply in cells containing a list of points
selectionMode points; // Optional
points
(
(2.25 0.5 0)
(2.75 0.5 0)
);
\endverbatim
All tutorials updated and simplified.
MRF (multiple reference frames) can now be used to simulate SRF (single
reference frame) cases by defining the MRF zone to include all the cells is the
mesh and applying appropriate boundary conditions. The huge advantage of this
is that MRF can easily be added to any solver by the addition of forcing terms
in the momentum equation and absolute velocity to relative flux conversions in
the formulation of the pressure equation rather than having to reformulate the
momentum and pressure system based on the relative velocity as in traditional
SRF. Also most of the OpenFOAM solver applications and all the solver modules
already support MRF.
To enable this generalisation of MRF the transformations necessary on the
velocity boundary conditions in the MRF zone can no longer be handled by the
MRFZone class itself but special adapted fvPatchFields are required. Although
this adds to the case setup it provides much greater flexibility and now complex
inlet/outlet conditions can be applied within the MRF zone, necessary for some
SRF case and which was not possible in the original MRF implementation. Now for
walls rotating within the MRF zone the new 'MRFnoSlip' velocity boundary
conditions must be applied, e.g. in the
tutorials/modules/incompressibleFluid/mixerVessel2DMRF/constant/MRFProperties
case:
boundaryField
{
rotor
{
type MRFnoSlip;
}
stator
{
type noSlip;
}
front
{
type empty;
}
back
{
type empty;
}
}
similarly for SRF cases, e.g. in the
tutorials/modules/incompressibleFluid/mixerSRF case:
boundaryField
{
inlet
{
type fixedValue;
value uniform (0 0 -10);
}
outlet
{
type pressureInletOutletVelocity;
value $internalField;
}
rotor
{
type MRFnoSlip;
}
outerWall
{
type noSlip;
}
cyclic_half0
{
type cyclic;
}
cyclic_half1
{
type cyclic;
}
}
For SRF case all the cells should be selected in the MRFproperties dictionary
which is achieved by simply setting the optional 'selectionMode' entry to all,
e.g.:
SRF
{
selectionMode all;
origin (0 0 0);
axis (0 0 1);
rpm 1000;
}
In the above the rotational speed is set in RPM rather than rad/s simply by
setting the 'rpm' entry rather than 'omega'.
The tutorials/modules/incompressibleFluid/rotor2DSRF case is more complex and
demonstrates a transient SRF simulation of a rotor requiring the free-stream
velocity to rotate around the apparently stationary rotor which is achieved
using the new 'MRFFreestreamVelocity' velocity boundary condition. The
equivalent simulation can be achieved by simply rotating the entire mesh and
keeping the free-stream flow stationary and this is demonstrated in the
tutorials/modules/incompressibleFluid/rotor2DRotating case for comparison.
The special SRFSimpleFoam and SRFPimpleFoam solvers are now redundant and have
been replaced by redirection scripts providing details of the case migration
process.
This prevents the need for a topoSet configuration. It also avoids a
potential error associated with duplicate specification of the geometry
of the solid region.
Also, the unnecessary ./Allclean has been removed, and some minor
re-naming has been done for clarity.
in which different solver modules can be selected in each region to for complex
conjugate heat-transfer and other combined physics problems such as FSI
(fluid-structure interaction).
For single-region simulations the solver module is selected, instantiated and
executed in the PIMPLE loop in the new foamRun application.
For multi-region simulations the set of solver modules, one for each region, are
selected, instantiated and executed in the multi-region PIMPLE loop of new the
foamMultiRun application.
This provides a very general, flexible and extensible framework for complex
coupled problems by creating more solver modules, either by converting existing
solver applications or creating new ones.
The current set of solver modules provided are:
isothermalFluid
Solver module for steady or transient turbulent flow of compressible
isothermal fluids with optional mesh motion and mesh topology changes.
Created from the rhoSimpleFoam, rhoPimpleFoam and buoyantFoam solvers but
without the energy equation, hence isothermal. The buoyant pressure
formulation corresponding to the buoyantFoam solver is selected
automatically by the presence of the p_rgh pressure field in the start-time
directory.
fluid
Solver module for steady or transient turbulent flow of compressible fluids
with heat-transfer for HVAC and similar applications, with optional
mesh motion and mesh topology changes.
Derived from the isothermalFluid solver module with the addition of the
energy equation from the rhoSimpleFoam, rhoPimpleFoam and buoyantFoam
solvers, thus providing the equivalent functionality of these three solvers.
multicomponentFluid
Solver module for steady or transient turbulent flow of compressible
reacting fluids with optional mesh motion and mesh topology changes.
Derived from the isothermalFluid solver module with the addition of
multicomponent thermophysical properties energy and specie mass-fraction
equations from the reactingFoam solver, thus providing the equivalent
functionality in reactingFoam and buoyantReactingFoam. Chemical reactions
and/or combustion modelling may be optionally selected to simulate reacting
systems including fires, explosions etc.
solid
Solver module for turbulent flow of compressible fluids for conjugate heat
transfer, HVAC and similar applications, with optional mesh motion and mesh
topology changes.
The solid solver module may be selected in solid regions of a CHT case, with
either the fluid or multicomponentFluid solver module in the fluid regions
and executed with foamMultiRun to provide functionality equivalent
chtMultiRegionFoam but in a flexible and extensible framework for future
extension to more complex coupled problems.
All the usual fvModels, fvConstraints, functionObjects etc. are available with
these solver modules to support simulations including body-forces, local sources,
Lagrangian clouds, liquid films etc. etc.
Converting compressibleInterFoam and multiphaseEulerFoam into solver modules
would provide a significant enhancement to the CHT capability and incompressible
solvers like pimpleFoam run in conjunction with solidDisplacementFoam in
foamMultiRun would be useful for a range of FSI problems. Many other
combinations of existing solvers converted into solver modules could prove
useful for a very wide range of complex combined physics simulations.
All tutorials from the rhoSimpleFoam, rhoPimpleFoam, buoyantFoam, reactingFoam,
buoyantReactingFoam and chtMultiRegionFoam solver applications replaced by
solver modules have been updated and moved into the tutorials/modules directory:
modules
├── CHT
│ ├── coolingCylinder2D
│ ├── coolingSphere
│ ├── heatedDuct
│ ├── heatExchanger
│ ├── reverseBurner
│ └── shellAndTubeHeatExchanger
├── fluid
│ ├── aerofoilNACA0012
│ ├── aerofoilNACA0012Steady
│ ├── angledDuct
│ ├── angledDuctExplicitFixedCoeff
│ ├── angledDuctLTS
│ ├── annularThermalMixer
│ ├── BernardCells
│ ├── blockedChannel
│ ├── buoyantCavity
│ ├── cavity
│ ├── circuitBoardCooling
│ ├── decompressionTank
│ ├── externalCoupledCavity
│ ├── forwardStep
│ ├── helmholtzResonance
│ ├── hotRadiationRoom
│ ├── hotRadiationRoomFvDOM
│ ├── hotRoom
│ ├── hotRoomBoussinesq
│ ├── hotRoomBoussinesqSteady
│ ├── hotRoomComfort
│ ├── iglooWithFridges
│ ├── mixerVessel2DMRF
│ ├── nacaAirfoil
│ ├── pitzDaily
│ ├── prism
│ ├── shockTube
│ ├── squareBend
│ ├── squareBendLiq
│ └── squareBendLiqSteady
└── multicomponentFluid
├── aachenBomb
├── counterFlowFlame2D
├── counterFlowFlame2D_GRI
├── counterFlowFlame2D_GRI_TDAC
├── counterFlowFlame2DLTS
├── counterFlowFlame2DLTS_GRI_TDAC
├── cylinder
├── DLR_A_LTS
├── filter
├── hotBoxes
├── membrane
├── parcelInBox
├── rivuletPanel
├── SandiaD_LTS
├── simplifiedSiwek
├── smallPoolFire2D
├── smallPoolFire3D
├── splashPanel
├── verticalChannel
├── verticalChannelLTS
└── verticalChannelSteady
Also redirection scripts are provided for the replaced solvers which call
foamRun -solver <solver module name> or foamMultiRun in the case of
chtMultiRegionFoam for backward-compatibility.
Documentation for foamRun and foamMultiRun:
Application
foamRun
Description
Loads and executes an OpenFOAM solver module either specified by the
optional \c solver entry in the \c controlDict or as a command-line
argument.
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
Usage
\b foamRun [OPTION]
- \par -solver <name>
Solver name
- \par -libs '(\"lib1.so\" ... \"libN.so\")'
Specify the additional libraries loaded
Example usage:
- To run a \c rhoPimpleFoam case by specifying the solver on the
command line:
\verbatim
foamRun -solver fluid
\endverbatim
- To update and run a \c rhoPimpleFoam case add the following entries to
the controlDict:
\verbatim
application foamRun;
solver fluid;
\endverbatim
then execute \c foamRun
Application
foamMultiRun
Description
Loads and executes an OpenFOAM solver modules for each region of a
multiregion simulation e.g. for conjugate heat transfer.
The region solvers are specified in the \c regionSolvers dictionary entry in
\c controlDict, containing a list of pairs of region and solver names,
e.g. for a two region case with one fluid region named
liquid and one solid region named tubeWall:
\verbatim
regionSolvers
{
liquid fluid;
tubeWall solid;
}
\endverbatim
The \c regionSolvers entry is a dictionary to support name substitutions to
simplify the specification of a single solver type for a set of
regions, e.g.
\verbatim
fluidSolver fluid;
solidSolver solid;
regionSolvers
{
tube1 $fluidSolver;
tubeWall1 solid;
tube2 $fluidSolver;
tubeWall2 solid;
tube3 $fluidSolver;
tubeWall3 solid;
}
\endverbatim
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
Usage
\b foamMultiRun [OPTION]
- \par -libs '(\"lib1.so\" ... \"libN.so\")'
Specify the additional libraries loaded
Example usage:
- To update and run a \c chtMultiRegion case add the following entries to
the controlDict:
\verbatim
application foamMultiRun;
regionSolvers
{
fluid fluid;
solid solid;
}
\endverbatim
then execute \c foamMultiRun
