Description
User convenience class to handle the input of time-varying rotational speed
in rad/s if \c omega is specified or rpm if \c rpm is specified.
Usage
For specifying the rotational speed in rpm of an MRF zone:
\verbatim
MRF
{
cellZone rotor;
origin (0 0 0);
axis (0 0 1);
rpm 60;
}
\endverbatim
or the equivalent specified in rad/s:
\verbatim
MRF
{
cellZone rotor;
origin (0 0 0);
axis (0 0 1);
rpm 6.28319;
}
\endverbatim
or for a tabulated ramped rotational speed of a solid body:
\verbatim
mover
{
type motionSolver;
libs ("libfvMeshMovers.so" "libfvMotionSolvers.so");
motionSolver solidBody;
cellZone innerCylinder;
solidBodyMotionFunction rotatingMotion;
origin (0 0 0);
axis (0 1 0);
rpm table
(
(0 0)
(0.01 6000)
(0.022 6000)
(0.03 4000)
(100 4000)
);
}
\endverbatim
The following classes have been updated to use the new Function1s::omega class:
solidBodyMotionFunctions::rotatingMotion
MRFZone
rotatingPressureInletOutletVelocityFvPatchVectorField
rotatingTotalPressureFvPatchScalarField
rotatingWallVelocityFvPatchVectorField
and all tutorials using these models and BCs updated to use rpm where appropriate.
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.
Field settings can now be specified within
createNonConformalCouplesDict. This allows for patchType overrides; for
example to create a jump condition over the coupling.
An alternate syntax has been added to facilitate this. If patch fields
do not need overriding then the old syntax can be used where patches
that are to be coupled are specified as a pair of names; e.g.:
fields yes;
nonConformalCouples
{
fan
{
patches (fan0 fan1);
transform none;
}
}
If patch fields do need overriding, then instead of the "patches" entry,
separate "owner" and "neighbour" sub-dictionaries should be used. These
can both contain a "patchFields" section detailing the boundary
conditions that apply to the newly created patches:
fields yes;
nonConformalCouples
{
fan
{
owner
{
patch fan0;
patchFields
{
p
{
type fanPressureJump;
patchType nonConformalCyclic;
jump uniform 0;
value uniform 0;
jumpTable polynomial 1((100 0));
}
}
}
neighbour
{
patch fan1;
patchFields
{
$../../owner/patchFields;
}
}
transform none;
}
}
In this example, only the pressure boundary condition is overridden on
the newly created non-conformal cyclic. All other fields will have the
basic constraint type (i.e., nonConformalCyclic) applied.
Settings for the individual non-conformal couples can now be put in a
"nonConformalCouples" sub-dictionary of the
system/createNonConformalCouplesDict. For example:
fields no;
nonConformalCouples // <-- new sub-dictionary
{
nonConformalCouple_none
{
patches (nonCouple1 nonCouple2);
transform none;
}
nonConformalCouple_30deg
{
patches (nonCoupleBehind nonCoupleAhead);
transform rotational;
rotationAxis (-1 0 0);
rotationCentre (0 0 0);
rotationAngle 30;
}
}
This permits settings to be #include-d from files that themselves
contain sub-dictionaries without the utility treating those
sub-dictionaries as if they specify a non-conformal coupling. It also
makes the syntax more comparable to that of createBafflesDict.
The new "nonConformalCouples" sub-dictionary is optional, so this change
is backwards compatible. The new syntax is recommended, however, and all
examples have been changed accordingly.
foamToVTK now supports cases with non-conformal patches. These are
excluded from the final output because their faces do not correspond to
anything in the conformal polyMesh.
In addition, patches are now excluded due to type or selection
consistently, regardless of the presence of the -allPatches option.
The time step adjustment now starts from the minimum of the deltaT
calculated from Courant condition (and other physical limits), and the
deltaT specified in the system/controlDict.
This means that a small deltaT setting in system/controlDict results in
a gradual increase up to the Courant number limited value. This can be
useful in maintaining stability at the start of a simulation.
This functionality is an accidental side-effect at best. It is being
reinstated as existing cases are reliant upon it. If additional control
of the time step in the initial stages of a simulation is needed, then
that should be achieved with a more explicit user control.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces pimpleFoam, pisoFoam and simpleFoam and all
the corresponding tutorials have been updated and moved to
tutorials/modules/incompressibleFluid.
Class
Foam::solvers::incompressibleFluid
Description
Solver module for steady or transient turbulent flow of incompressible
isothermal fluids with optional mesh motion and change.
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
Optional fvModels and fvConstraints are provided to enhance the simulation
in many ways including adding various sources, constraining or limiting
the solution.
Reference:
\verbatim
Greenshields, C. J., & Weller, H. G. (2022).
Notes on Computational Fluid Dynamics: General Principles.
CFD Direct Ltd.: Reading, UK.
\endverbatim
SourceFiles
incompressibleFluid.C
See also
Foam::solvers::fluidSolver
Foam::solvers::isothermalFluid
to avoid name clash with the VoF surfaceTensionModels when both the
multiphaseEulerFoam and compressibleInterFoam libraries are linked into a single
executable.
The new solver modules cannot provide the equivalent functionality of the -list
options available in the solver applications so foamToC has been developed as a
better, more general and flexible alternative, providing a means to print any or
all run-time selection tables in any or all libraries and search the tables for
any particular entries and print which library files the corresponding tables
are in, e.g.
foamToC -solver fluid -table fvPatchScalarField
Contents of table fvPatchScalarField, base type fvPatchField:
advective libfiniteVolume.so
calculated libfiniteVolume.so
codedFixedValue libfiniteVolume.so
codedMixed libfiniteVolume.so
compressible::alphatJayatillekeWallFunctionlibthermophysicalTransportModels.so
compressible::alphatWallFunction libthermophysicalTransportModels.so
compressible::thermalBaffle1D<eConstSolidThermoPhysics>libthermophysicalTransportModels.so
compressible::thermalBaffle1D<ePowerSolidThermoPhysics>libthermophysicalTransportModels.so
compressible::turbulentTemperatureCoupledBaffleMixedlibthermophysicalTransportModels.so
compressible::turbulentTemperatureRadCoupledMixedlibthermophysicalTransportModels.so
.
.
.
foamToC -solver fluid -search compressible::alphatWallFunction
compressible::alphatWallFunction is in tables
fvPatchField
fvPatchScalarField libthermophysicalTransportModels.so
and the very useful -allLibs option allows ALL libraries to be searched to find
in which table and which library file a particular model in in for example:
foamToC -allLibs -search phaseTurbulenceStabilisation
Loading libraries:
libtwoPhaseSurfaceTension.so
libcv2DMesh.so
libODE.so
.
.
.
phaseTurbulenceStabilisation is in tables
fvModel libmultiphaseEulerFoamFvModels.so
Application
foamToC
Description
Run-time selection table of contents printing and interrogation.
The run-time selection tables are populated by the optionally specified
solver class and any additional libraries listed in the \c -libs option or
all libraries using the \c -allLibs option. Once populated the tables can
be searched and printed by a range of options listed below. Table entries
are printed with the corresponding library they are in to aid selection
and the addition of \c libs entries to ensure availability to the solver.
Usage
\b foamToC [OPTION]
- \par -solver \<name\>
Specify the solver class
- \par -libs '(\"lib1.so\" ... \"libN.so\")'
Specify the additional libraries to load
- \par -allLibs
Load all libraries
- \par switches,
List all available debug, info and optimisation switches
- \par all,
List the contents of all the run-time selection tables
- \par tables
List the run-time selection table names (this is the default action)
- \par table \<name\>
List the contents of the specified table or the list sub-tables
- \par search \<name\>
Search for and list the tables containing the given entry
- \par scalarBCs,
List scalar field boundary conditions (fvPatchField<scalar>)
- \par vectorBCs,
List vector field boundary conditions (fvPatchField<vector>)
- \par functionObjects,
List functionObjects
- \par fvModels,
List fvModels
- \par fvConstraints,
List fvConstraints
Example usage:
- Print the list of scalar boundary conditions (fvPatchField<scalar>)
provided by the \c fluid solver without additional libraries:
\verbatim
foamToC -solver fluid -scalarBCs
\endverbatim
- Print the list of RAS momentum transport models provided by the
\c fluid solver:
\verbatim
foamToC -solver fluid -table RAScompressibleMomentumTransportModel
\endverbatim
- Print the list of functionObjects provided by the
\c multicomponentFluid solver with the libfieldFunctionObjects.so
library:
\verbatim
foamToC -solver multicomponentFluid \
-libs '("libfieldFunctionObjects.so")' -functionObjects
\endverbatim
- Print a complete list of all run-time selection tables:
\verbatim
foamToC -allLibs -tables
or
foamToC -allLibs
\endverbatim
- Print a complete list of all entries in all run-time selection tables:
\verbatim
foamToC -allLibs -all
\endverbatim
Application
foamPostProcess
Description
Execute the set of functionObjects specified in the selected dictionary
(which defaults to system/controlDict) or on the command-line for the
selected set of times on the selected set of fields.
The functionObjects are either executed directly or for the solver
optionally specified as a command-line argument.
Usage
\b foamPostProcess [OPTION]
- \par -dict <file>
Read control dictionary from specified location
- \par -solver <name>
Solver name
- \par -libs '(\"lib1.so\" ... \"libN.so\")'
Specify the additional libraries loaded
-\par -region <name>
Specify the region
- \par -func <name>
Specify the name of the functionObject to execute, e.g. Q
- \par -funcs <list>
Specify the names of the functionObjects to execute, e.g. '(Q div(U))'
- \par -field <name>
Specify the name of the field to be processed, e.g. U
- \par -fields <list>
Specify a list of fields to be processed,
e.g. '(U T p)' - regular expressions not currently supported
- \par -time <ranges>
comma-separated time ranges - eg, ':10,20,40:70,1000:'
- \par -latestTime
Select the latest time
- \par -list
List the available configured functionObjects
Example usage:
- Print the list of available configured functionObjects:
\verbatim
foamPostProcess -list
\endverbatim
- Execute the functionObjects specified in the controlDict of the
fluid region for all the available times:
\verbatim
foamPostProcess -region fluid
\endverbatim
- Execute the functionObjects specified in the controlDict
for the 'fluid' solver in the 'cooling' region for the latest time only:
\verbatim
foamPostProcess -solver fluid -region cooling -latestTime
\endverbatim
A postProcess redirection script is provided for backward-compatibility.
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
Full backward-compatibility is provided which support for both multiComponentMixture and
multiComponentPhaseModel provided but all tutorials have been updated.
Now that the reaction system, chemistry and combustion models are completely
separate from the multicomponent mixture thermophysical properties package that
supports them it is inconsistent that thermo is named reactionThermo and the
name multicomponentThermo better describes the purpose and functionality.
This has required implementation of finer control of stitching in the
fvMesh read constructor and readUpdate methods. Stitching is now
controlled independently of the mesh changers. Full-geometric stitching
is now always the default unless explicitly overridden in the calls to
fvMesh's read methods.
If a "patch" selection is made for a cyclic patch, surfaceFieldValue now
also selects faces on any associated processor cyclic patches. This
ensures that the serial and parallel operations are equivalent.
Points now always get decomposed or reconstructed for the initial face
instance. This means that they are available in the constant directory
even if decomposition/reconstruction begins at a later time which has
its own moved points field.
