The keyword 'select' is now used to specify the cell, face or point set
selection method consistently across all classes requiring this functionality.
'select' replaces the inconsistently named 'regionType' and 'selectionMode'
keywords used previously but backwards-compatibility is provided for user
convenience. All configuration files and tutorials have been updated.
Examples of 'select' from the tutorial cases:
functionObjects:
cellZoneAverage
{
type volFieldValue;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
writeInterval 1;
fields (p);
select cellZone;
cellZone injection;
operation volAverage;
writeFields false;
}
#includeFunc populationBalanceSizeDistribution
(
name=numberDensity,
populationBalance=aggregates,
select=cellZone,
cellZone=outlet,
functionType=numberDensity,
coordinateType=projectedAreaDiameter,
allCoordinates=yes,
normalise=yes,
logTransform=yes
)
fvModel:
cylinderHeat
{
type heatSource;
select all;
q 5e7;
}
fvConstraint:
momentumForce
{
type meanVelocityForce;
select all;
Ubar (0.1335 0 0);
}
This is a more intuitive keyword than "funcName" or "entryName". A
function object's name and corresponding output directory can now be
renamed as follows:
#includeFunc patchAverage
(
name=cylinderT, // <-- was funcName=... or entryName=...
region=fluid,
patch=fluid_to_solid,
field=T
)
Some packaged functions previously relied on a "name" argument that
related to an aspect of the function; e.g., the name of the faceZone
used by the faceZoneFlowRate function. These have been disambiguated.
This has also made them consistent with the preferred input syntax of
the underlying function objects.
Examples of the changed #includeFunc entries are shown below:
#includeFunc faceZoneAverage
(
faceZone=f0, // <-- was name=f0
U
)
#includeFunc faceZoneFlowRate
(
faceZone=f0 // <-- was name=f0
)
#includeFunc populationBalanceSizeDistribution
(
populationBalance=bubbles,
regionType=cellZone,
cellZone=injection, // <-- was name=injection
functionType=volumeDensity,
coordinateType=diameter,
normalise=yes
)
#includeFunc triSurfaceAverage
(
triSurface=mid.obj, // <-- was name=mid.obj
p
)
#includeFunc triSurfaceVolumetricFlowRate
(
triSurface=mid.obj // <-- was name=mid.obj
)
#includeFunc uniform
(
fieldType=volScalarField,
fieldName=alpha, // <-- was name=alpha
dimensions=[0 0 0 0 0 0 0],
value=0.2
)
so that the same option with a rational name is also available for #includeModel
and #includeConstraint. Support for funcName is maintained for
backwards-compatibility.
The input syntax of the heatTransfer and interRegionHeatTransfer
fvModels has been modified to make it more usable and consistent with
the rest of OpenFOAM.
The settings for area per unit volume (AoV) are no longer controlled by
the heat transfer coefficient model. Instead they belong to the fvModel
itself and are specified within the base fvModel's dictionary.
The heat transfer coefficient model has been renamed to
"heatTransferCoefficientModel" to better account for exactly what it
does. It is now selected using an entry called
"heatTransferCoefficientModel", rather than "type". As a sub-sub model,
"type" clashes with the outer fvModel's "type" entry unless a Coeffs
dictionary is used. This change has made the Coeffs sub-dictionary
optional, as it should be, unless model-specific keywords require
disambiguation.
A heat transfer coefficient model can now be specified as follows:
heatTransfer1
{
type heatTransfer;
heatTransferCoeffs
{
selectionMode all;
semiImplicit true;
Ta 298;
AoV 100;
heatTransferCoefficientModel variable; // constant, function1
constantCoeffs
{
htc 1000;
}
variableCoeffs
{
a 0.332;
b 0.5;
c 0.333333;
Pr 0.7;
L 0.1;
}
}
}
Alternatively, the coefficient sub-dictionaries can all be omitted,
giving the following syntax:
heatTransfer1
{
type heatTransfer;
selectionMode all;
semiImplicit true;
Ta 298;
AoV 100;
heatTransferCoefficientModel variable;
a 0.332;
b 0.5;
c 0.333333;
Pr 0.7;
L 0.1;
}
Two fvModels have been added, densityConstraintSource and
pressureConstraintSource, for constraining the density or pressure of
zero-dimensional cases. The constrained property's variation in time is
specified by means of a Function1.
The constraints are maintained by adding or removing an appropriate
amount of mass. Properties are added or removed with this mass at their
current values. Both constraints therefore represent uniform expansion
or contraction in an infinite space. In the case of the pressure
constraint, the compressibility is used to determine this amount of
mass, and in the case of non-linear equations of state iteration may be
necessary to enforce the constraint accurately.
These models can be used to extend the concept of a zero-dimensional
simulation to one that uniformly expands or contracts, or features a
mass source or sink.
Example specification of a time-varying density constraint, in
constant/fvModels:
densityConstraintSource1
{
type densityConstraintSource;
rho
{
type scale;
values
(
(0 1.16)
(1 1.16)
(1.1 2.02)
(10 2.02)
);
}
}
Example specification of a constant pressure constraint:
pressureConstraintSource1
{
type pressureConstraintSource;
p 1e5;
}
An example in which the pressure is constrained is provided. This
example shows the reaction of nc7h16, and duplicates the behaviour of
the corresponding chemFoam case.
#includeModel includes an fvModel configuration file into the fvModels file
#includeConstraint includes an fvModel configuration file into the fvConstraints file
These operate in the same manner as #includeFunc does for functionObjects and
search the etc/caseDicts/fvModels and etc/caseDicts/fvConstraints directories
for configuration files and apply optional argument substitution.
Class
Foam::functionEntries::includeFvModelEntry
Description
Specify a fvModel dictionary file to include, expects the
fvModel name to follow with option arguments (without quotes).
Searches for fvModel dictionary file in user/group/shipped
directories allowing for version-specific and version-independent files
using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/caseDicts/fvModels
- ~/.OpenFOAM/caseDicts/fvModels
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/etc/caseDicts/fvModels
- $WM_PROJECT_SITE/etc/caseDicts/fvModels
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/etc/caseDicts/fvModels
- $WM_PROJECT_INST_DIR/site/etc/caseDicts/fvModels
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/caseDicts/fvModels
The optional field arguments included in the name are inserted in 'field' or
'fields' entries in the fvModel dictionary and included in the name
of the fvModel entry to avoid conflict.
Examples:
\verbatim
#includeModel clouds
#includeModel surfaceFilms
\endverbatim
Other dictionary entries may also be specified using named arguments.
See also
Foam::includeFvConstraintEntry
Foam::includeFuncEntry
Class
Foam::functionEntries::includeFvConstraintEntry
Description
Specify a fvConstraint dictionary file to include, expects the
fvConstraint name to follow with option arguments (without quotes).
Searches for fvConstraint dictionary file in user/group/shipped
directories allowing for version-specific and version-independent files
using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/caseDicts/fvConstraints
- ~/.OpenFOAM/caseDicts/fvConstraints
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/etc/caseDicts/fvConstraints
- $WM_PROJECT_SITE/etc/caseDicts/fvConstraints
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/etc/caseDicts/fvConstraints
- $WM_PROJECT_INST_DIR/site/etc/caseDicts/fvConstraints
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/caseDicts/fvConstraints
The optional field arguments included in the name are inserted in 'field' or
'fields' entries in the fvConstraint dictionary and included in the name
of the fvConstraint entry to avoid conflict.
Examples:
\verbatim
#includeConstraint limitPressure(minFactor=0.1, maxFactor=2)
#includeConstraint limitTemperature(min=101, max=1000)
\endverbatim
or for a multiphase case:
\verbatim
#includeConstraint limitLowPressure(min=1e4)
#includeConstraint limitTemperature(phase=steam, min=270, max=2000)
#includeConstraint limitTemperature(phase=water, min=270, max=2000)
\endverbatim
Other dictionary entries may also be specified using named arguments.
See also
Foam::includeFvModelEntry
Foam::includeFuncEntry
particleFoam has been superseded and replaced by the more general functions
solver module executed by the foamRun application:
foamRun -solver functions
The incompressibleFluid solver specified by either the subSolver or if not
present the solver entry in the controlDict is instantiated to provide the
physical fields needed by fvModel functionObject in which the clouds fvModel is
selected to evolve the Lagrangian particles. See:
tutorials/modules/incompressibleFluid/hopperParticles
tutorials/modules/incompressibleFluid/mixerVessel2DParticles
rhoParticleFoam has been superseded and replaced by the more general functions
solver module executed by the foamRun application:
foamRun -solver functions
The isothermalFluid solver specified by either the subSolver or if not present
the solver entry in the controlDict is instantiated to provide the physical
fields needed by fvModel functionObject in which the clouds fvModel is selected
to evolve the Lagrangian particles.
Description
Solver module to execute the \c functionObjects for a specified solver
The solver specified by either the \c subSolver or if not present the \c
solver entry in the \c controlDict is instantiated to provide the physical
fields needed by the \c functionObjects. The \c functionObjects are then
instantiated from the specifications are read from the \c functions entry in
the \c controlDict and executed in a time-loop also controlled by entries in
\c controlDict and the \c maxDeltaT() returned by the sub-solver.
The fields and other objects registered by the sub-solver are set to
NO_WRITE as they are not changed by the execution of the functionObjects and
should not be written out each write-time. Fields and other objects created
and changed by the execution of the functionObjects are written out.
solvers::functions in conjunction with the scalarTransport functionObject
replaces scalarTransportFoam and provide more general handling of the scalar
diffusivity.
By solving for U and e rather than rhoU and rhoE the convection and stress
matrices can be combined and solved together avoiding the need for Strang
splitting. Conservation of rho*U and rho*E is ensured by constructing and
solving the three equations in sequence, constructing each using the results of
the solution of the previous equations.
Tutorials have been updated to use the new consistent names within the
wall boiling system. The changes are backwards compatible so all
tutorials should run both before and after this change.
This boundary condition now solves for the wall temperature by interval
bisection, which should be significantly more robust than the previous
fixed-point iteration procedure. There is a new non-dimensional
"tolerance" setting that controls how tightly this solution procedure
solves the wall temperature. The "relax" setting is no longer used.
The boundary condition no longer triggers re-evaluation of the
temperature condition in order to re-calculate the heat flux within the
solution iteration. Instead, it extracts physical coefficients from the
form of the boundary condition and uses these to form a linearised
approximation of the heat flux. This is a more general approach, and
will not trigger side-effects associated with re-evaluating the
temperature condition.
The fixedMultiphaseHeatFlux condition has been replaced by a
uniformFixedMultiphaseHeatFlux condition, which constructs a mixed
constraint which portions a specified heat flux between the phases in
such a way as to keep the boundary temperature uniform across all
phases. This can be applied to all phases. It is no longer necessary to
apply a heat flux model to one "master" phase, then map the resulting
temperature to the others. An example specification of this boundary
condition is as follows:
wall
{
type uniformFixedMultiphaseHeatFlux;
q 1000;
relax 0.3;
value $internalField;
}
The wall boiling tutorials have been updated to use these new functions,
and time-varying heat input has been used to replace the
stop-modify-restart pattern present in the single-region cases.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces rhoCentralFoam and all the corresponding
tutorials have been updated and moved to tutorials/modules/shockFluid.
Unlike rhoCentralFoam shockFluid supports mesh refinement/unrefinement, topology
change, run-time mesh-to-mesh mapping, load-balancing in addition to general
mesh-motion.
The tutorials/modules/shockFluid/movingCone case has been updated to demonstrate
run-time mesh-to-mesh mapping mesh topology change based on the
tutorials/modules/incompressibleFluid/movingCone. shockFluid s
Description
Solver module for density-based solution of compressible flow
Based on central-upwind schemes of Kurganov and Tadmor with support for
mesh-motion and topology change.
Reference:
\verbatim
Greenshields, C. J., Weller, H. G., Gasparini, L.,
& Reese, J. M. (2010).
Implementation of semi‐discrete, non‐staggered central schemes
in a colocated, polyhedral, finite volume framework,
for high‐speed viscous flows.
International journal for numerical methods in fluids, 63(1), 1-21.
\endverbatim
SourceFiles
shockFluid.C
See also
Foam::solvers::fluidSolver
Foam::solvers::incompressibleFluid
This option means that a one field can be mapped to another within the
same patch without specifying the patch name. E.g.:
walls
{
type mappedValue;
//neighbourPatch walls; // <-- Previously required. Still supported.
samePatch yes; // <-- New alternative specification
field T.liquid;
value $internalField;
}
This is useful when the boundary condition is specified using a regular
expression for the patch name.
"wall_.*"
{
type mappedValue;
//neighbourPatch ???; // <-- No unique name can be given
samePatch yes; // <-- Still works
field T.liquid;
value $internalField;
}
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces compressibleMultiphaseInterFoam and all the
corresponding tutorials have been updated and moved to
tutorials/modules/compressibleMultiphaseVoF.
compressibleMultiphaseVoF is derived from the multiphaseVoFSolver which adds
compressible multiphase capability to the VoFSolver base-class used as the basis
of all two-phase and multiphase VoF solvers.
Class
Foam::solvers::compressibleMultiphaseVoF
Description
Solver module for the solution of multiple compressible, isothermal
immiscible fluids using a VOF (volume of fluid) phase-fraction based
interface capturing approach, with optional mesh motion and mesh topology
changes including adaptive re-meshing.
The momentum and other fluid properties are of the "mixture" and a single
momentum equation is solved.
A mixture approach for momentum transport is provided in which a single
laminar, RAS or LES model is selected to model the momentum stress.
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
SourceFiles
compressibleMultiphaseVoF.C
See also
Foam::solvers::VoFSolver
Foam::solvers::multiphaseVoFSolver
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces multiphaseInterFoam and all the
corresponding tutorials have been updated and moved to
tutorials/modules/incompressibleMultiphaseVoF.
incompressibleMultiphaseVoF is derived from the multiphaseVoFSolver which adds
multiphase capability to the VoFSolver base-class used as the basis of all
two-phase and multiphase VoF solvers.
Class
Foam::solvers::incompressibleMultiphaseVoF
Description
Solver module for the solution of multiple incompressible, isothermal
immiscible fluids using a VOF (volume of fluid) phase-fraction based
interface capturing approach, with optional mesh motion and mesh topology
changes including adaptive re-meshing.
The momentum and other fluid properties are of the "mixture" and a single
momentum equation is solved.
A mixture approach for momentum transport is provided in which a single
laminar, RAS or LES model is selected to model the momentum stress.
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
SourceFiles
incompressibleMultiphaseVoF.C
See also
Foam::solvers::VoFSolver
Foam::solvers::multiphaseVoFSolver
The standard Jayatilleke thermal wall function now permits evaluation
via static functions. The boiling wall function now uses these
functions, thereby removing the phase-Jayatilleke base class and
associated duplication of the Jayatilleke model.
It is now possible to map from one field to another within the same
patch, using the mappedValue boundary condition. The restriction is that
the mapping must be from a different field, otherwise field values are
being assigned to themselves, which produces an undefined result.
The mappedValue boundary condition can now be used in place of the
copiedFixedValue condition in the multiphaseEuler module. The
copiedFixedValue condition has therefore been removed.
In addition, the error messages that result from casting a patch to its
mapping engine (mappedPatchBase) have been standardised, and made more
specific to the situation in which the mapping is applied. It may be
inappropriate, for example, to map within the same region or patch.
These cases are now identified and appropriate error messages are
generated.
The error messages have also been made IO errors, so they now provide
context with regards to the dictionary entries that they relate to.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces solidDisplacementFoam and
solidEquilibriumDisplacementFoam and all the corresponding tutorials have been
updated and moved to tutorials/modules/solidDisplacement.
Class
Foam::solvers::solidDisplacement
Description
Solver module for steady or transient segregated finite-volume solution of
linear-elastic, small-strain deformation of a solid body, with optional
thermal diffusion and thermal stresses.
Solves for the displacement vector field D, also generating the stress
tensor field sigma, including the thermal stress contribution if selected.
SourceFiles
solidDisplacement.C
The accelerationFactor option in solidEquilibriumDisplacementFoam is now
available in solidDisplacementFoam when running steady-state, providing a >5x
speed-up to convergence of the updated beamEndLoad case. This makes
solidEquilibriumDisplacementFoam redundant and it has been removed.
so that the same BC can be used for both solidDisplacementFoam and
solidEquilibriumDisplacementFoam. Also updated the beamEndLoad tutorial and
added a solidDisplacementFoam version to test the combined BC.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces XiFoam and all the corresponding
tutorials have been updated and moved to tutorials/modules/XiFluid.
Class
Foam::solvers::XiFluid
Description
Solver module for compressible premixed/partially-premixed combustion with
turbulence modelling.
Combusting RANS code using the b-Xi two-equation model.
Xi may be obtained by either the solution of the Xi transport
equation or from an algebraic expression. Both approaches are
based on Gulder's flame speed correlation which has been shown
to be appropriate by comparison with the results from the
spectral model.
Strain effects are encorporated directly into the Xi equation
but not in the algebraic approximation. Further work need to be
done on this issue, particularly regarding the enhanced removal rate
caused by flame compression. Analysis using results of the spectral
model will be required.
For cases involving very lean Propane flames or other flames which are
very strain-sensitive, a transport equation for the laminar flame
speed is present. This equation is derived using heuristic arguments
involving the strain time scale and the strain-rate at extinction.
the transport velocity is the same as that for the Xi equation.
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, chemical reactions,
combustion, Lagrangian particles, radiation, surface film etc. and
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
XiFluid.C
See also
Foam::solvers::fluidSolver
Foam::solvers::isothermalFluid
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces interFoam and all the corresponding
tutorials have been updated and moved to tutorials/modules/incompressibleVoF.
Both incompressibleVoF and compressibleVoF solver modules are derived from the
common two-phase VoF base-class solvers::VoFSolver which handles the
complexities of VoF interface-compression, boundedness and conservation with
2nd-order schemes in space and time using the semi-implicit MULES limiter and
solution proceedure. This maximises code re-use, improves readability and
simplifies maintenance.
Class
Foam::solvers::incompressibleVoF
Description
Solver module for for 2 incompressible, isothermal immiscible fluids using a
VOF (volume of fluid) phase-fraction based interface capturing approach,
with optional mesh motion and mesh topology changes including adaptive
re-meshing.
The momentum and other fluid properties are of the "mixture" and a single
momentum equation is solved.
Either mixture or two-phase transport modelling may be selected. In the
mixture approach a single laminar, RAS or LES model is selected to model the
momentum stress. In the Euler-Euler two-phase approach separate laminar,
RAS or LES selected models are selected for each of the phases.
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, Lagrangian
particles, surface film etc. and constraining or limiting the solution.
SourceFiles
incompressibleVoF.C
See also
Foam::solvers::VoFSolver
Foam::solvers::compressibleVoF
In order to ensure temperature consistency between the phases it is necessary to
solve for the mixture temperature rather than the mixture energy or phase
energies which makes it very difficult to conserve energy. The new temperature
equation is a temperature correction on the combined phase energy equations
which will conserve the phase and mixture energies at convergence. The
heat-flux (Laplacian) term is maintained in mixture temperature form so
heat-transfer boundary conditions, in particular for CHT, remain in terms of the
mixture kappaEff. The fvModels are applied to the phase energy equations and
the implicit part converted into an implicit term in the temperature correction
part of the equation to improve convergence and stability.
This development has required some change to the alphaEqn.H and interFoam has
been updated for consistency in preparation for conversion into the
solvers::incompressibleVoF modular module.
All compressibleVoF fvModels and tutorial cases have been updated for the above
change. Note that two entries are now required for the convection terms in the
temperature equation, one for explicit phase energy terms and another for the
implicit phase temperature correction terms, e.g.
tutorials/modules/compressibleVoF/ballValve
div(alphaRhoPhi,e) Gauss limitedLinear 1;
div(alphaRhoPhi,T) Gauss upwind;
In the above the upwind scheme is selected for the phase temperature correction
terms as they are corrections and will converge to a zero contribution. However
there may be cases which converge better if the same scheme is used for both the
energy and temperature terms, more testing is required.
The new optional PIMPLE control transportPredictionFirst is used to select if
the transport modelling predictor is executed ever PIMPLE iteration or only on
the first, which is the default.
Also the transportCorr() function has been renamed correctTransport() for
consistency and the tutorials updated to use the new control name
transportCorrectionFinal instead of the previous name turbOnFinalIterOnly;
support for turbOnFinalIterOnly is maintained for backwards-compatibility.
With the addition of the compressibleInterPhaseThermophysicalTransportModel
thermophysicalTransportModel the compressibleVoF modular solver now support
conjugate heat transfer (CHT).
Th new tutorials/modules/CHT/VoFcoolingCylinder2D tutorial case is provided to
demonstrate this functionality and shows a heated ceramic rod with air flowing
over the top and water underneath.
This function object writes graphs of patch face values, area-averaged in
planes perpendicular to a given direction. It adaptively grades the
distribution of graph points to match the resolution of the mesh.
Example of function object specification:
patchCutLayerAverage1
{
type patchCutLayerAverage;
libs ("libpatchCutLayerAverageFunctionObject.so");
writeControl writeTime;
writeInterval 1;
patch lowerWall;
direction (1 0 0);
nPoints 100;
interpolate no;
fields (p U);
axis x;
setFormat raw;
}
A packaged function object is also included, which permits the following
syntax to be used, either with #includeFunc in the system/controlDict,
or with the -func option to foamPostProcess:
graphPatchCutLayerAverage
(
funcName=aerofoilLowerPressure,
patch=aerofoilLower,
direction=(0.15 -0.016 0),
nPoints=100,
p
)
angleUnits is a more logical name for the user-input as it specifies the units
of the angles written rather than the format of the numbers. The previous name
angleFormat is supported for backwards-compatibility
Class
Foam::functionObjects::rigidBodyState
Description
Writes the rigid body motion state.
Usage
\table
Property | Description | Required | Default value
type | type name: rigidBodyState | yes |
angleUnits | degrees or radians | no | radians
\endtable
Example of function object specification:
\verbatim
rigidBodyState
{
type rigidBodyState;
libs ("librigidBodyState.so");
angleUnits degrees;
}
\endverbatim
Class
Foam::functionObjects::sixDoFRigidBodyState
Description
Writes the 6-DoF motion state.
Example of function object specification:
\verbatim
sixDoFRigidBodyState
{
type sixDoFRigidBodyState;
libs ("libsixDoFRigidBodyState.so");
angleUnits degrees;
}
\endverbatim
Usage
\table
Property | Description | Required | Default value
type | type name: sixDoFRigidBodyState | yes |
angleUnits | degrees or radians | no | radian
\endtable
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 localInteraction model now no longer requires specification of an
interaction on any constrained patch type (e.g., symmetry, cyclic, ...).
Non-constrained types (patch, wall, ...) require an interaction to be
specified as before and will trigger an error if this is not the case.
In addition, constrained patches can be overridden by providing a
'patchType' specifier, in the same way as would be done to override a
constrained boundary condition for finite volume.
The filter tutorial now correctly demonstrates something unique; i.e.,
particles rebounding from a cyclic. It has therefore been reinstated.
Resolves (properly) bug report https://bugs.openfoam.org/view.php?id=3923
A set of routines for cutting polyhedra have been added. These can cut
polyhedral cells based on the adjacent point values and an iso-value
which defines the surface. The method operates directly on the
polyhedral cells; it does not decompose them into tetrahedra at any
point. The routines can compute the cut topology as well as integrals of
properties above and below the cut surface.
An iso-surface algorithm has been added based on these polyhedral
cutting routines. It is significantly more robust than the previous
algorithm, and produces compact surfaces equivalent to the previous
algorithm's maximum filtering level. It is also approximately 3 times
faster than the previous algorithm, and 10 times faster when run
repeatedly on the same set of cells (this is because some addressing is
cached and reused).
This algorithm is used by the 'isoSurface', 'distanceSurface' and
'cutPlane' sampled surfaces.
The 'cutPlane' sampled surface is a renaming of 'cuttingPlane' to make
it consistent with the corresponding packaged function. The name
'cuttingPlane' has been retained for backwards compatibility and can
still be used to select a 'cutPlane' surface. The legacy 'plane' surface
has been removed.
The 'average' keyword has been removed from specification of these
sampled surfaces as cell-centred values are no longer used in the
generation of or interpolation to an iso-surface. The 'filtering'
keyword has also been removed as it relates to options within the
previous algorithm. Zone support has been reinstated into the
'isoSurface' sampled surface. Interpolation to all these sampled
surfaces has been corrected to exactly match the user-selected
interpolation scheme, and the interpolation procedure no longer
unnecessarily re-generates data that is already available.
