MRF requires mapping from a given set of polyMesh cells and faces to
internal and boundary faces of the finite volume system. It therefore
has to use the polyBFacePatches and polyBFacePatchFaces maps in order to
be compatible with NCC. This has been implemented, and now MRF should be
fully compatible with NCC.
Solvers ensure fluxes are maintained and updated correctly after topology change
and it no longer the responsibility of fvMeshTopoChangersRefiner to attempt
this.
The '-region' option has been leveraged to significantly simplify the
meshing and decomposition in the movingCone cases. These cases have also
been corrected to restore the variation in decomposition between the
different meshes, which is important for thoroughly testing the patch
field mapping. The shockFluid case has also had its duration extended a
little in order to span the final mesh mapping time.
The method to update phi in PDRFoamAutoRefine has been superseded by rhoUf in
all other compressible solvers and PDRFoam needs to be updated, requiring
funding. PDRFoamAutoRefine is no longer maintained.
The patch field 'autoMap' and 'rmap' functions have been replaced with a
single 'map' function that can used to do any form of in-place
patch-to-patch mapping. The exact form of mapping is now controlled
entirely by the mapper object.
An example 'map' function is shown below:
void nutkRoughWallFunctionFvPatchScalarField::map
(
const fvPatchScalarField& ptf,
const fvPatchFieldMapper& mapper
)
{
nutkWallFunctionFvPatchScalarField::map(ptf, mapper);
const nutkRoughWallFunctionFvPatchScalarField& nrwfpsf =
refCast<const nutkRoughWallFunctionFvPatchScalarField>(ptf);
mapper(Ks_, nrwfpsf.Ks_);
mapper(Cs_, nrwfpsf.Cs_);
}
This single function replaces these two previous functions:
void nutkRoughWallFunctionFvPatchScalarField::autoMap
(
const fvPatchFieldMapper& m
)
{
nutkWallFunctionFvPatchScalarField::autoMap(m);
m(Ks_, Ks_);
m(Cs_, Cs_);
}
void nutkRoughWallFunctionFvPatchScalarField::rmap
(
const fvPatchScalarField& ptf,
const labelList& addr
)
{
nutkWallFunctionFvPatchScalarField::rmap(ptf, addr);
const nutkRoughWallFunctionFvPatchScalarField& nrwfpsf =
refCast<const nutkRoughWallFunctionFvPatchScalarField>(ptf);
Ks_.rmap(nrwfpsf.Ks_, addr);
Cs_.rmap(nrwfpsf.Cs_, addr);
}
Calls to 'autoMap' should be replaced with calls to 'map' with the same
mapper object and the patch field itself provided as the source. Calls
to 'rmap' should be replaced with calls to 'map' by wrapping the
addressing in a 'reverseFvPatchFieldMapper' (or
'reversePointPatchFieldMapper') object.
This change simplifies the creation of new patch fields and hence
improves extensibility. It also provides more options regarding general
mapping strategies between patches. Previously, general abstracted
mapping was only possible in 'autoMap'; i.e., from a patch to itself.
Now, general mapping is possible between different patches.
Replacing volRegion removes unnecessary functionality duplication and ensures
cell set selection is consistent between functionObjects, fvModels and
fvConstraints for user convenience and reducing the code maintenance overhead.
Description
General cell set selection class for models that apply to sub-sets
of the mesh.
Currently supports cell selection from a set of points, a specified cellSet
or cellZone or all of the cells. The selection method can either be
specified explicitly using the \c select entry or inferred from the
presence of either a \c cellSet, \c cellZone or \c points entry. The \c
select entry is required to select \c all cells.
Usage
Examples:
\verbatim
// Apply everywhere
select all;
// Apply within a given cellSet
select cellSet; // Optional
cellSet rotor;
// Apply within a given cellZone
select cellZone; // Optional
cellZone rotor;
// Apply in cells containing a list of points
select points; // Optional
points
(
(2.25 0.5 0)
(2.75 0.5 0)
);
\endverbatim
This is an optimisation control that allows the user to specify whether
or not mapping is re-calculated as a result of mesh motion. It is true
by default, as this is guaranteed to work in all scenarios.
Setting this control to false will provide computational benefit for
cases in which mapped patches move consistently, but if the patches do
not move consistently then it will result in incorrect behaviour.
Mesh motion is now supported in solid regions, but with the restriction
that it must be a solid-body-type motion. The mesh must not deform; all
cell volumes and face area magnitudes must remain constant. An error
will be generated if a motion strategy is selected that does not obey
this constraint.
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.
The moleFractions function has been simplified and generalised. It no
longer needs to execute on construction, as function objects now have
the ability to execute at the start of a simulation. It can also now
construct a thermo model if none exists, simplifying its use as a post
processing operation. A packaged function has been provided, so that all
that is needed to execute the function is the following setting in the
functions section of the system/controlDict:
#includeFunc moleFractions
Alternatively, it can be executed on the command line as follows:
foamPostProcess -func moleFractions
A new massFractions function has also been added which converts mole
fraction fields (e.g., X_CH4, X_O2, etc...), or moles fields (n_CH4,
n_O2, etc...) to the corresponding mass fraction fields. This function,
by contrast to the moleFractions function described above, should not be
used at run-time. It should only be used to initialise a simulation in
which molar data is known and needs converting to mass-fractions. If at
the point of execution a thermo model exists, or mass-fraction fields
are found on disk, then this function will exit with an error rather
than invalidating the existing mass-fraction data. Packaging is provided
that allows the function to be executed to initialise a case as follows:
foamPostProcess -func massFractions
These functions adjusts the time step to match a reaction process. The
adjustTimeStepToChemistry fucntion adjusts based on the chemistry
model's stored chemical time step, and adjustTimeStepToCombustion
adjusts to match bulk reaction time scales. The latter requires
specification of a Courant-like number, to control approximately how
much of the reaction is permitted to be completed in a single
time-step.
These functions allow the solver to temporally resolve chemical changes,
in order to better couple the reactions with the transport, or in order
improve the time-accuracy of post-processing.
Example usage by dictionary specification:
adjustTimeStepToChemistry1
{
type adjustTimeStepToChemistry;
libs ("libchemistryModel.so");
}
adjustTimeStepToCombustion1
{
type adjustTimeStepToCombustion;
libs ("libchemistryModel.so");
maxCo 0.1;
}
Example usage via the included packaged function:
#includeFunc adjustTimeStepToChemistry
#includeFunc adjustTimeStepToCombustion(maxCo=0.1)
#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.
