foamToC: New run-time selection table of contents printing and interrogation utility
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
The timeName() function simply returns the dimensionedScalar::name() which holds
the user-time name of the current time and now that timeName() is no longer
virtual the dimensionedScalar::name() can be called directly. The timeName()
function implementation is maintained for backward-compatibility.
The previous fluidThermophysicalTransportModel typedef has been renamed
fluidThermoThermophysicalTransportModel as it is instantiated on fluidThermo,
freeing the name fluidThermophysicalTransportModel for the new base-class.
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
Mesh motion and topology change are now combinable run-time selectable options
within fvMesh, replacing the restrictive dynamicFvMesh which supported only
motion OR topology change.
All solvers which instantiated a dynamicFvMesh now instantiate an fvMesh which
reads the optional constant/dynamicFvMeshDict to construct an fvMeshMover and/or
an fvMeshTopoChanger. These two are specified within the optional mover and
topoChanger sub-dictionaries of dynamicFvMeshDict.
When the fvMesh is updated the fvMeshTopoChanger is first executed which can
change the mesh topology in anyway, adding or removing points as required, for
example for automatic mesh refinement/unrefinement, and all registered fields
are mapped onto the updated mesh. The fvMeshMover is then executed which moved
the points only and calculates the cell volume change and corresponding
mesh-fluxes for conservative moving mesh transport. If multiple topological
changes or movements are required these would be combined into special
fvMeshMovers and fvMeshTopoChangers which handle the processing of a list of
changes, e.g. solidBodyMotionFunctions:multiMotion.
The tutorials/multiphase/interFoam/laminar/sloshingTank3D3DoF case has been
updated to demonstrate this new functionality by combining solid-body motion
with mesh refinement/unrefinement:
/*--------------------------------*- C++ -*----------------------------------*\
========= |
\\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\\ / O peration | Website: https://openfoam.org
\\ / A nd | Version: dev
\\/ M anipulation |
\*---------------------------------------------------------------------------*/
FoamFile
{
format ascii;
class dictionary;
location "constant";
object dynamicMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
mover
{
type motionSolver;
libs ("libfvMeshMovers.so" "libfvMotionSolvers.so");
motionSolver solidBody;
solidBodyMotionFunction SDA;
CofG (0 0 0);
lamda 50;
rollAmax 0.2;
rollAmin 0.1;
heaveA 4;
swayA 2.4;
Q 2;
Tp 14;
Tpn 12;
dTi 0.06;
dTp -0.001;
}
topoChanger
{
type refiner;
libs ("libfvMeshTopoChangers.so");
// How often to refine
refineInterval 1;
// Field to be refinement on
field alpha.water;
// Refine field in between lower..upper
lowerRefineLevel 0.001;
upperRefineLevel 0.999;
// Have slower than 2:1 refinement
nBufferLayers 1;
// Refine cells only up to maxRefinement levels
maxRefinement 1;
// Stop refinement if maxCells reached
maxCells 200000;
// Flux field and corresponding velocity field. Fluxes on changed
// faces get recalculated by interpolating the velocity. Use 'none'
// on surfaceScalarFields that do not need to be reinterpolated.
correctFluxes
(
(phi none)
(nHatf none)
(rhoPhi none)
(alphaPhi.water none)
(meshPhi none)
(meshPhi_0 none)
(ghf none)
);
// Write the refinement level as a volScalarField
dumpLevel true;
}
// ************************************************************************* //
Note that currently this is the only working combination of mesh-motion with
topology change within the new framework and further development is required to
update the set of topology changers so that topology changes with mapping are
separated from the mesh-motion so that they can be combined with any of the
other movements or topology changes in any manner.
All of the solvers and tutorials have been updated to use the new form of
dynamicMeshDict but backward-compatibility was not practical due to the complete
reorganisation of the mesh change structure.
to provide a single consistent code and user interface to the specification of
physical properties in both single-phase and multi-phase solvers. This redesign
simplifies usage and reduces code duplication in run-time selectable solver
options such as 'functionObjects' and 'fvModels'.
* physicalProperties
Single abstract base-class for all fluid and solid physical property classes.
Physical properties for a single fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties' dictionary.
Physical properties for a phase fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties.<phase>' dictionary.
This replaces the previous inconsistent naming convention of
'transportProperties' for incompressible solvers and
'thermophysicalProperties' for compressible solvers.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the
'physicalProperties' dictionary does not exist.
* phaseProperties
All multi-phase solvers (VoF and Euler-Euler) now read the list of phases and
interfacial models and coefficients from the
'constant/<region>/phaseProperties' dictionary.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the 'phaseProperties'
dictionary does not exist. For incompressible VoF solvers the
'transportProperties' is automatically upgraded to 'phaseProperties' and the
two 'physicalProperties.<phase>' dictionary for the phase properties.
* viscosity
Abstract base-class (interface) for all fluids.
Having a single interface for the viscosity of all types of fluids facilitated
a substantial simplification of the 'momentumTransport' library, avoiding the
need for a layer of templating and providing total consistency between
incompressible/compressible and single-phase/multi-phase laminar, RAS and LES
momentum transport models. This allows the generalised Newtonian viscosity
models to be used in the same form within laminar as well as RAS and LES
momentum transport closures in any solver. Strain-rate dependent viscosity
modelling is particularly useful with low-Reynolds number turbulence closures
for non-Newtonian fluids where the effect of bulk shear near the walls on the
viscosity is a dominant effect. Within this framework it would also be
possible to implement generalised Newtonian models dependent on turbulent as
well as mean strain-rate if suitable model formulations are available.
* visosityModel
Run-time selectable Newtonian viscosity model for incompressible fluids
providing the 'viscosity' interface for 'momentumTransport' models.
Currently a 'constant' Newtonian viscosity model is provided but the structure
supports more complex functions of time, space and fields registered to the
region database.
Strain-rate dependent non-Newtonian viscosity models have been removed from
this level and handled in a more general way within the 'momentumTransport'
library, see section 'viscosity' above.
The 'constant' viscosity model is selected in the 'physicalProperties'
dictionary by
viscosityModel constant;
which is equivalent to the previous entry in the 'transportProperties'
dictionary
transportModel Newtonian;
but backward-compatibility is provided for both the keyword and model
type.
* thermophysicalModels
To avoid propagating the unnecessary constructors from 'dictionary' into the
new 'physicalProperties' abstract base-class this entire structure has been
removed from the 'thermophysicalModels' library. The only use for this
constructor was in 'thermalBaffle' which now reads the 'physicalProperties'
dictionary from the baffle region directory which is far simpler and more
consistent and significantly reduces the amount of constructor code in the
'thermophysicalModels' library.
* compressibleInterFoam
The creation of the 'viscosity' interface for the 'momentumTransport' models
allows the complex 'twoPhaseMixtureThermo' derived from 'rhoThermo' to be
replaced with the much simpler 'compressibleTwoPhaseMixture' derived from the
'viscosity' interface, avoiding the myriad of unused thermodynamic functions
required by 'rhoThermo' to be defined for the mixture.
Same for 'compressibleMultiphaseMixture' in 'compressibleMultiphaseInterFoam'.
This is a significant improvement in code and input consistency, simplifying
maintenance and further development as well as enhancing usability.
Henry G. Weller
CFD Direct Ltd.
The -dict option is now handled correctly and consistently across all
applications with -dict options. The logic associated with doing so has
been centralised.
If a relative path is given to the -dict option, then it is assumed to
be relative to the case directory. If an absolute path is given, then it
is used without reference to the case directory. In both cases, if the
path is found to be a directory, then the standard dictionary name is
appended to the path.
Resolves bug report http://bugs.openfoam.org/view.php?id=3692
The MomentumTransportModels library now builds of a standard set of
phase-incompressible and phase-compressible models. This replaces most
solver-specific builds of these models.
This has been made possible by the addition of a new
"dynamicTransportModel" interface, from which all transport classes used
by the momentum transport models now derive. For the purpose of
disambiguation, the old "transportModel" has also been renamed
"kinematicTransportModel".
This change has been made in order to create a consistent definition of
phase-incompressible and phase-compressible MomentumTransportModels,
which can then be looked up by functionObjects, fvModels, and similar.
Some solvers still build specific momentum transport models, but these
are now in addition to the standard set. The solver does not build all
the models it uses.
There are also corresponding centralised builds of phase dependent
ThermophysicalTransportModels.
The new fvModels is a general interface to optional physical models in the
finite volume framework, providing sources to the governing conservation
equations, thus ensuring consistency and conservation. This structure is used
not only for simple sources and forces but also provides a general run-time
selection interface for more complex models such as radiation and film, in the
future this will be extended to Lagrangian, reaction, combustion etc. For such
complex models the 'correct()' function is provided to update the state of these
models at the beginning of the PIMPLE loop.
fvModels are specified in the optional constant/fvModels dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The new fvConstraints is a general interface to optional numerical constraints
applied to the matrices of the governing equations after construction and/or to
the resulting field after solution. This system allows arbitrary changes to
either the matrix or solution to ensure numerical or other constraints and hence
violates consistency with the governing equations and conservation but it often
useful to ensure numerical stability, particularly during the initial start-up
period of a run. Complex manipulations can be achieved with fvConstraints, for
example 'meanVelocityForce' used to maintain a specified mean velocity in a
cyclic channel by manipulating the momentum matrix and the velocity solution.
fvConstraints are specified in the optional system/fvConstraints dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The separation of fvOptions into fvModels and fvConstraints provides a rational
and consistent separation between physical and numerical models which is easier
to understand and reason about, avoids the confusing issue of location of the
controlling dictionary file, improves maintainability and easier to extend to
handle current and future requirements for optional complex physical models and
numerical constraints.
There is now only one -listSwitches argument available to the
applications; -listUnsetSwitches and -listRegisteredSwitches have been
removed. -listSwitches prints everything, now also including the values.
It also categorises the output based on whether the switch has a
default, if it has the same value as that default, and whether or not it
is registered with a re-reader.
The list of debug switches in etc/controlDict has been reduced to only
the switches which have non-zero values. In general the list of valid
switches varies per application and per library, so it is not possible
to keep a single definitive list of all switches. The -listSwitches
argument provides the definitive list on a per applicaton basis.
Setting of defaults for named enum optimisation switches has been added.
The standard set of Lagrangian clouds are now selectable at run-time.
This means that a solver that supports Lagrangian modelling can now use
any type of cloud (with some restrictions). Previously, solvers were
hard-coded to use specific cloud modelling. In addition, a cloud-list
structure has been added so that solvers may select multiple clouds,
rather than just one.
The new system is controlled as follows:
- If only a single cloud is required, then the settings for the
Lagrangian modelling should be placed in a constant/cloudProperties
file.
- If multiple clouds are required, then a constant/clouds file should be
created containing a list of cloud names defined by the user. Each
named cloud then reads settings from a corresponding
constant/<cloudName>Properties file. Clouds are evolved sequentially
in the order in which they are listed in the constant/clouds file.
- If no clouds are required, then the constant/cloudProperties file and
constant/clouds file should be omitted.
The constant/cloudProperties or constant/<cloudName>Properties files are
the same as previous cloud properties files; e.g.,
constant/kinematicCloudProperties or constant/reactingCloud1Properties,
except that they now also require an additional top-level "type" entry
to select which type of cloud is to be used. The available options for
this entry are:
type cloud; // A basic cloud of solid
// particles. Includes forces,
// patch interaction, injection,
// dispersion and stochastic
// collisions. Same as the cloud
// previously used by
// rhoParticleFoam
// (uncoupledKinematicParticleFoam)
type collidingCloud; // As "cloud" but with resolved
// collision modelling. Same as the
// cloud previously used by DPMFoam
// and particleFoam
// (icoUncoupledKinematicParticleFoam)
type MPPICCloud; // As "cloud" but with MPPIC
// collision modelling. Same as the
// cloud previously used by
// MPPICFoam.
type thermoCloud; // As "cloud" but with
// thermodynamic modelling and heat
// transfer with the carrier phase.
// Same as the limestone cloud
// previously used by
// coalChemistryFoam.
type reactingCloud; // As "thermoCloud" but with phase
// change and mass transfer
// coupling with the carrier
// phase. Same as the cloud
// previously used in fireFoam.
type reactingMultiphaseCloud; // As "reactingCloud" but with
// particles that contain multiple
// phases. Same as the clouds
// previously used in
// reactingParcelFoam and
// simpleReactingParcelFoam and the
// coal cloud used in
// coalChemistryFoam.
type sprayCloud; // As "reactingCloud" but with
// additional spray-specific
// collision and breakup modelling.
// Same as the cloud previously
// used in sprayFoam and
// engineFoam.
The first three clouds are not thermally coupled, so are available in
all Lagrangian solvers. The last four are thermally coupled and require
access to the carrier thermodynamic model, so are only available in
compressible Lagrangian solvers.
This change has reduced the number of solvers necessary to provide the
same functionality; solvers that previously differed only in their
Lagrangian modelling can now be combined. The Lagrangian solvers have
therefore been consolidated with consistent naming as follows.
denseParticleFoam: Replaces DPMFoam and MPPICFoam
reactingParticleFoam: Replaces sprayFoam and coalChemistryFoam
simpleReactingParticleFoam: Replaces simpleReactingParcelFoam
buoyantReactingParticleFoam: Replaces reactingParcelFoam
fireFoam and engineFoam remain, although fireFoam is likely to be merged
into buoyantReactingParticleFoam in the future once the additional
functionality it provides is generalised.
Some additional minor functionality has also been added to certain
solvers:
- denseParticleFoam has a "cloudForceSplit" control which can be set in
system/fvOptions.PIMPLE. This provides three methods for handling the
cloud momentum coupling, each of which have different trade-off-s
regarding numerical artefacts in the velocity field. See
denseParticleFoam.C for more information, and also bug report #3385.
- reactingParticleFoam and buoyantReactingParticleFoam now support
moving mesh in order to permit sharing parts of their implementation
with engineFoam.
providing the shear-stress term in the momentum equation for incompressible and
compressible Newtonian, non-Newtonian and visco-elastic laminar flow as well as
Reynolds averaged and large-eddy simulation of turbulent flow.
The general deviatoric shear-stress term provided by the MomentumTransportModels
library is named divDevTau for compressible flow and divDevSigma (sigma =
tau/rho) for incompressible flow, the spherical part of the shear-stress is
assumed to be either included in the pressure or handled separately. The
corresponding stress function sigma is also provided which in the case of
Reynolds stress closure returns the effective Reynolds stress (including the
laminar contribution) or for other Reynolds averaged or large-eddy turbulence
closures returns the modelled Reynolds stress or sub-grid stress respectively.
For visco-elastic flow the sigma function returns the effective total stress
including the visco-elastic and Newtonian contributions.
For thermal flow the heat-flux generated by thermal diffusion is now handled by
the separate ThermophysicalTransportModels library allowing independent run-time
selection of the heat-flux model.
During the development of the MomentumTransportModels library significant effort
has been put into rationalising the components and supporting libraries,
removing redundant code, updating names to provide a more logical, consistent
and extensible interface and aid further development and maintenance. All
solvers and tutorials have been updated correspondingly and backward
compatibility of the input dictionaries provided.
Henry G. Weller
CFD Direct Ltd.
for
db/functionObjects/timeControl/timeControl.H: timeControls
primitives/bools/Switch/Switch.H: class switchType
primitives/strings/fileName/fileName.H: fileType
primitives/strings/wordRe/wordRe.H: compOption
Improvements to existing functionality
--------------------------------------
- MPI is initialised without thread support if it is not needed e.g. uncollated
- Use native c++11 threading; avoids problem with static destruction order.
- etc/cellModels now only read if needed.
- etc/controlDict can now be read from the environment variable FOAM_CONTROLDICT
- Uniform files (e.g. '0/uniform/time') are now read only once on the master only
(with the masterUncollated or collated file handlers)
- collated format writes to 'processorsNNN' instead of 'processors'. The file
format is unchanged.
- Thread buffer and file buffer size are no longer limited to 2Gb.
The global controlDict file contains parameters for file handling. Under some
circumstances, e.g. running in parallel on a system without NFS, the user may
need to set some parameters, e.g. fileHandler, before the global controlDict
file is read from file. To support this, OpenFOAM now allows the global
controlDict to be read as a string set to the FOAM_CONTROLDICT environment
variable.
The FOAM_CONTROLDICT environment variable can be set to the content the global
controlDict file, e.g. from a sh/bash shell:
export FOAM_CONTROLDICT=$(foamDictionary $FOAM_ETC/controlDict)
FOAM_CONTROLDICT can then be passed to mpirun using the -x option, e.g.:
mpirun -np 2 -x FOAM_CONTROLDICT simpleFoam -parallel
Note that while this avoids the need for NFS to read the OpenFOAM configuration
the executable still needs to load shared libraries which must either be copied
locally or available via NFS or equivalent.
New: Multiple IO ranks
----------------------
The masterUncollated and collated fileHandlers can now use multiple ranks for
writing e.g.:
mpirun -np 6 simpleFoam -parallel -ioRanks '(0 3)'
In this example ranks 0 ('processor0') and 3 ('processor3') now handle all the
I/O. Rank 0 handles 0,1,2 and rank 3 handles 3,4,5. The set of IO ranks should always
include 0 as first element and be sorted in increasing order.
The collated fileHandler uses the directory naming processorsNNN_XXX-YYY where
NNN is the total number of processors and XXX and YYY are first and last
processor in the rank, e.g. in above example the directories would be
processors6_0-2
processors6_3-5
and each of the collated files in these contains data of the local ranks
only. The same naming also applies when e.g. running decomposePar:
decomposePar -fileHandler collated -ioRanks '(0 3)'
New: Distributed data
---------------------
The individual root directories can be placed on different hosts with different
paths if necessary. In the current framework it is necessary to specify the
root per slave process but this has been simplified with the option of specifying
the root per host with the -hostRoots command line option:
mpirun -np 6 simpleFoam -parallel -ioRanks '(0 3)' \
-hostRoots '("machineA" "/tmp/" "machineB" "/tmp")'
The hostRoots option is followed by a list of machine name + root directory, the
machine name can contain regular expressions.
New: hostCollated
-----------------
The new hostCollated fileHandler automatically sets the 'ioRanks' according to
the host name with the lowest rank e.g. to run simpleFoam on 6 processors with
ranks 0-2 on machineA and ranks 3-5 on machineB with the machines specified in
the hostfile:
mpirun -np 6 --hostfile hostfile simpleFoam -parallel -fileHandler hostCollated
This is equivalent to
mpirun -np 6 --hostfile hostfile simpleFoam -parallel -fileHandler collated -ioRanks '(0 3)'
This example will write directories:
processors6_0-2/
processors6_3-5/
A typical example would use distributed data e.g. no two nodes, machineA and
machineB, each with three processes:
decomposePar -fileHandler collated -case cavity
# Copy case (constant/*, system/*, processors6/) to master:
rsync -a cavity machineA:/tmp/
# Create root on slave:
ssh machineB mkdir -p /tmp/cavity
# Run
mpirun --hostfile hostfile icoFoam \
-case /tmp/cavity -parallel -fileHandler hostCollated \
-hostRoots '("machineA" "/tmp" "machineB" "/tmp")'
Contributed by Mattijs Janssens
When an OpenFOAM simulation runs in parallel, the data for decomposed fields and
mesh(es) has historically been stored in multiple files within separate
directories for each processor. Processor directories are named 'processorN',
where N is the processor number.
This commit introduces an alternative "collated" file format where the data for
each decomposed field (and mesh) is collated into a single file, which is
written and read on the master processor. The files are stored in a single
directory named 'processors'.
The new format produces significantly fewer files - one per field, instead of N
per field. For large parallel cases, this avoids the restriction on the number
of open files imposed by the operating system limits.
The file writing can be threaded allowing the simulation to continue running
while the data is being written to file. NFS (Network File System) is not
needed when using the the collated format and additionally, there is an option
to run without NFS with the original uncollated approach, known as
"masterUncollated".
The controls for the file handling are in the OptimisationSwitches of
etc/controlDict:
OptimisationSwitches
{
...
//- Parallel IO file handler
// uncollated (default), collated or masterUncollated
fileHandler uncollated;
//- collated: thread buffer size for queued file writes.
// If set to 0 or not sufficient for the file size threading is not used.
// Default: 2e9
maxThreadFileBufferSize 2e9;
//- masterUncollated: non-blocking buffer size.
// If the file exceeds this buffer size scheduled transfer is used.
// Default: 2e9
maxMasterFileBufferSize 2e9;
}
When using the collated file handling, memory is allocated for the data in the
thread. maxThreadFileBufferSize sets the maximum size of memory in bytes that
is allocated. If the data exceeds this size, the write does not use threading.
When using the masterUncollated file handling, non-blocking MPI communication
requires a sufficiently large memory buffer on the master node.
maxMasterFileBufferSize sets the maximum size in bytes of the buffer. If the
data exceeds this size, the system uses scheduled communication.
The installation defaults for the fileHandler choice, maxThreadFileBufferSize
and maxMasterFileBufferSize (set in etc/controlDict) can be over-ridden within
the case controlDict file, like other parameters. Additionally the fileHandler
can be set by:
- the "-fileHandler" command line argument;
- a FOAM_FILEHANDLER environment variable.
A foamFormatConvert utility allows users to convert files between the collated
and uncollated formats, e.g.
mpirun -np 2 foamFormatConvert -parallel -fileHandler uncollated
An example case demonstrating the file handling methods is provided in:
$FOAM_TUTORIALS/IO/fileHandling
The work was undertaken by Mattijs Janssens, in collaboration with Henry Weller.
Initially the listSwitches functions depended directly on argList functionality
but this has now been factored out so that the listSwitches functions are more
general and require only debug functionality.
Provides better context for the available boundary conditions, fvOptions,
functionObjects etc. and thus returns only those available to and compatible
with the particular application.
e.g.
pimpleFoam -help
Usage: pimpleFoam [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-listFunctionObjects
List functionObjects
-listFvOptions List fvOptions
-listRegisteredSwitches
List switches registered for run-time modification
-listScalarBCs List scalar field boundary conditions (fvPatchField<scalar>)
-listSwitches List switches declared in libraries but not set in
etc/controlDict
-listTurbulenceModels
List turbulenceModels
-listUnsetSwitches
List switches declared in libraries but not set in
etc/controlDict
-listVectorBCs List vector field boundary conditions (fvPatchField<vector>)
-noFunctionObjects
do not execute functionObjects
-parallel run in parallel
-postProcess Execute functionObjects only
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
pimpleFoam listTurbulenceModels
pimpleFoam -listTurbulenceModels
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: dev |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : dev-39c46019e44f
Exec : pimpleFoam -listTurbulenceModels
Date : Jun 10 2017
Time : 21:37:49
Host : "dm"
PID : 675
Case : /home/dm2/henry/OpenFOAM/OpenFOAM-dev
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
SetNaN : Initialising allocated memory to NaN (FOAM_SETNAN).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Turbulence models
3
(
LES
RAS
laminar
)
RAS models
18
(
LRR
LamBremhorstKE
LaunderSharmaKE
LienCubicKE
LienLeschziner
RNGkEpsilon
SSG
ShihQuadraticKE
SpalartAllmaras
kEpsilon
kOmega
kOmegaSST
kOmegaSSTLM
kOmegaSSTSAS
kkLOmega
qZeta
realizableKE
v2f
)
LES models
10
(
DeardorffDiffStress
Smagorinsky
SpalartAllmarasDDES
SpalartAllmarasDES
SpalartAllmarasIDDES
WALE
dynamicKEqn
dynamicLagrangian
kEqn
kOmegaSSTDES
)
Further work will be needed to support the -listTurbulenceModels option in
multiphase solvers.
This supports the abstraction of the set of fields from the field code
generation macros making it easier to change the set of fields supported
by OpenFOAM. This functionality is demonstrated in the updated
fvPatchFields macros and will be applied to the rest of the field code
generation macros in the future.
with the more general and flexible 'postProcess' utility and '-postProcess' solver option
Rationale
---------
Both the 'postProcess' utility and '-postProcess' solver option use the
same extensive set of functionObjects available for data-processing
during the run avoiding the substantial code duplication necessary for
the 'foamCalc' and 'postCalc' utilities and simplifying maintenance.
Additionally consistency is guaranteed between solver data processing
and post-processing.
The functionObjects have been substantially re-written and generalized
to simplify development and encourage contribution.
Configuration
-------------
An extensive set of simple functionObject configuration files are
provided in
OpenFOAM-dev/etc/caseDicts/postProcessing
and more will be added in the future. These can either be copied into
'<case>/system' directory and included into the 'controlDict.functions'
sub-dictionary or included directly from 'etc/caseDicts/postProcessing'
using the '#includeEtc' directive or the new and more convenient
'#includeFunc' directive which searches the
'<etc>/caseDicts/postProcessing' directories for the selected
functionObject, e.g.
functions
{
#includeFunc Q
#includeFunc Lambda2
}
'#includeFunc' first searches the '<case>/system' directory in case
there is a local configuration.
Description of #includeFunc
---------------------------
Specify a functionObject dictionary file to include, expects the
functionObject name to follow (without quotes).
Search for functionObject dictionary file in
user/group/shipped directories.
The search scheme allows for version-specific and
version-independent files using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/caseDicts/postProcessing
- ~/.OpenFOAM/caseDicts/postProcessing
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/caseDicts/postProcessing
- $WM_PROJECT_SITE/caseDicts/postProcessing
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/caseDicts/postProcessing
- $WM_PROJECT_INST_DIR/site/caseDicts/postProcessing
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/caseDicts/postProcessing
An example of the \c \#includeFunc directive:
\verbatim
#includeFunc <funcName>
\endverbatim
postProcess
-----------
The 'postProcess' utility and '-postProcess' solver option provide the
same set of controls to execute functionObjects after the run either by
reading a specified set of fields to process in the case of
'postProcess' or by reading all fields and models required to start the
run in the case of '-postProcess' for each selected time:
postProcess -help
Usage: postProcess [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-constant include the 'constant/' dir in the times list
-dict <file> read control dictionary from specified location
-field <name> specify the name of the field to be processed, e.g. U
-fields <list> specify a list of fields to be processed, e.g. '(U T p)' -
regular expressions not currently supported
-func <name> specify the name of the functionObject to execute, e.g. Q
-funcs <list> specify the names of the functionObjects to execute, e.g.
'(Q div(U))'
-latestTime select the latest time
-newTimes select the new times
-noFunctionObjects
do not execute functionObjects
-noZero exclude the '0/' dir from the times list, has precedence
over the -withZero option
-parallel run in parallel
-region <name> specify alternative mesh region
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-time <ranges> comma-separated time ranges - eg, ':10,20,40:70,1000:'
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
pimpleFoam -postProcess -help
Usage: pimpleFoam [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-constant include the 'constant/' dir in the times list
-dict <file> read control dictionary from specified location
-field <name> specify the name of the field to be processed, e.g. U
-fields <list> specify a list of fields to be processed, e.g. '(U T p)' -
regular expressions not currently supported
-func <name> specify the name of the functionObject to execute, e.g. Q
-funcs <list> specify the names of the functionObjects to execute, e.g.
'(Q div(U))'
-latestTime select the latest time
-newTimes select the new times
-noFunctionObjects
do not execute functionObjects
-noZero exclude the '0/' dir from the times list, has precedence
over the -withZero option
-parallel run in parallel
-postProcess Execute functionObjects only
-region <name> specify alternative mesh region
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-time <ranges> comma-separated time ranges - eg, ':10,20,40:70,1000:'
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
The functionObjects to execute may be specified on the command-line
using the '-func' option for a single functionObject or '-funcs' for a
list, e.g.
postProcess -func Q
postProcess -funcs '(div(U) div(phi))'
In the case of 'Q' the default field to process is 'U' which is
specified in and read from the configuration file but this may be
overridden thus:
postProcess -func 'Q(Ua)'
as is done in the example above to calculate the two forms of the divergence of
the velocity field. Additional fields which the functionObjects may depend on
can be specified using the '-field' or '-fields' options.
The 'postProcess' utility can only be used to execute functionObjects which
process fields present in the time directories. However, functionObjects which
depend on fields obtained from models, e.g. properties derived from turbulence
models can be executed using the '-postProcess' of the appropriate solver, e.g.
pisoFoam -postProcess -func PecletNo
or
sonicFoam -postProcess -func MachNo
In this case all required fields will have already been read so the '-field' or
'-fields' options are not be needed.
Henry G. Weller
CFD Direct Ltd.
To compile with 64bit labels set
WM_LABEL_SIZE=64
in ~/OpenFOAM/dev/prefs.sh
source ~/.bashrc
then Allwmake in OpenFOAM-dev.
This will build into for example OpenFOAM-dev/platforms/linux64ClangDPInt64Opt
If WM_LABEL_SIZE is unset or set to 32:
WM_LABEL_SIZE=32
the build would be placed into OpenFOAM-dev/platforms/linux64ClangDPInt32Opt
Thus both 32bit and 64bit label builds can coexist without problem.
