A dynamicMotionSolverFvMesh must now use a "motionSolver" or
"motionSolvers" entry to select the underlying motion solver. For
example, in constant/dynamicMeshDict:
dynamicFvMesh dynamicMotionSolverFvMesh;
motionSolverLibs ("librigidBodyMeshMotion.so");
motionSolver rigidBodyMotion;
...
Previously the motion solver could also be specified with the keyword
"solver", but this resulted in a name clash with rigid body solvers
which are frequently specified in the same scope. For this reason, the
"solver" and "solvers" entries have been removed.
End points of topoSet cylinder sources should now be specified as
"point1" and "point2", which is consistent with other parts of the code.
The previous keywords, "p1" and "p2" have been retained for backwards
compatibility but may be removed in future.
These allows for dictionary lookups which fall back to a different,
older keyword. Both lookup and lookup-or-default methods are provided;
lookupBackwardsCompatible and lookupOrDefaultBackwardsCompatible,
respectively.
A list of keywords are provided to these methods. The first is taken to
be the current preferred name of the entry, and subsequent elements are
considered to relate to older syntax. These keywords are tried in turn.
If nothing are found then any errors or messages printed relate to the
first keyword in the list.
This centralises backwards compatability logic and allows for current
backwards compatibility settings to be conveniently searched for.
Setting the 'mixtureDiffusionCoefficients' true the mass diffusion coefficient
functions with respect to the mixture 'Dm' are used directly but if set false
the binary mass diffusion coefficient functions 'D' are evaluated and mixed to
provide the mass diffusion with respect to the mixture, e.g.
Usage
\verbatim
laminar
{
model FickianFourier;
mixtureDiffusionCoefficients yes;
Dm // [m^2/s]
{
O2 1e-2;
O3 5e-2;
N2 1e-2;
}
DT // [kg/m/s] Optional
{
O2 1e-2;
O3 5e-2;
N2 1e-2;
}
}
\endverbatim
or if binary mass diffusion coefficient functions are available they can be
mixed to form the mass diffusion coefficients w.r.t. the mixture:
\verbatim
laminar
{
model FickianFourier;
mixtureDiffusionCoefficients no;
D // [m^2/s]
{
O2-O2 1e-2;
O3-O3 5e-2;
N2-N2 1e-2;
O3-O2 5e-2;
O3-N2 5e-2;
O2-N2 1e-2;
}
DT // [kg/m/s] Optional
{
O2 1e-2;
O3 5e-2;
N2 1e-2;
}
}
\endverbatim
Description
Multi-component Maxwell Stefan generalized Fick's law diffusion coefficients
and Fourier based temperature gradient heat flux model with optional Soret
thermal diffusion of species for laminar flow.
The binary diffusion coefficients are specified as Function2<scalar>s of
pressure and temperature but independent of composition.
The heat flux source is implemented as an implicit energy correction to the
temperature gradient based flux source. At convergence the energy
correction is 0.
References:
\verbatim
Taylor, R., & Krishna, R. (1993).
Multicomponent mass transfer (Vol. 2).
John Wiley & Sons.
Merk, H. J. (1959).
The macroscopic equations for simultaneous heat and mass transfer
in isotropic, continuous and closed systems.
Applied Scientific Research,
Section A, 8(1), 73-99.
\endverbatim
Usage
\verbatim
laminar
{
model MaxwellStefanFourier;
D // [m^2/s]
{
O2_O2 1e-2;
O3_O3 5e-2;
N2_N2 1e-2;
O3_O2 5e-2;
O3_N2 5e-2;
O2_N2 1e-2;
O2 1e-2;
O3 5e-2;
N2 1e-2;
}
DT // [kg/m/s] Optional
{
O2 1e-2;
O3 5e-2;
N2 1e-2;
}
}
\endverbatim
This change allows fvOptions to access and evaluate each other. This
means an option can be written that applies a source value proportional
to that in another option.
For example, you might have an fvOption specifying a mass source term in
the rhoEqn. You could now write a corresponding momentum source fvOption
which takes the velocity associated with that mass source as an input.
It would look up the mass source option to get the mass flow rate and
multiply it by the user supplied velocity to get the momentum source.
This prevents the user having to convert from the primitive variable
(e.g., velocity) to the conserved variable (e.g., momentum) when
specifying source terms.
Lookup is provided by means of a new [](const word&) operator on the
fvOptionList, and evaluation is achieved by adding ()(...) operators to
the fvOptions similar to those already available in the fvOptionList.
Example usage is shown below.
const fv::optionList& fvOptions(fv::options::New(mesh_));
const fv::option& fvOption = fvOptions[sourceName_]; // <-- Lookup
tmp<volScalarField> source(fvOption(field) & field); // <-- Evaluation
If the surfaceFieldValue function object is used to compute an
area-normal average or integral of a vector quantity, the result will
now be correctly written out as a scalar.
Previously surfaceFieldValue was limited to writing the same type as the
input field. A vector area-normal average or integral therefore had to
be written out as a vector. This was done by setting the x component to
the result, and the y and z components to zero. This was considered to
be counter-intuitive.
A volumetric flow rate through a tri-surface can now be obtained using
the volumetricFlowRateTriSurface preconfigured function object, using
the following entry in system/controlDict:
fuctions
{
#includeFunc "volumetricFlowRateTriSurface(name=surface.stl)"
}
Where "surface.stl" is a tri-surface file in the constant/triSurface
directory. An example of this has been added to the
incompressible/pimpleFoam/RAS/impeller tutorial case.
Note that when possible, it is preferable to use the flowRatePatch or
flowRateFaceZone functions, as these make direct use of the flux and
therefore report a value that is exactly that computed by the solver.
volumetricFlowRateTriSurface, by contrast, does interpolation of the
velocity field which introduces error.
In addition, a minor fix has been made to the underlying
surfaceFieldValue function object so that it does not need a zone/set
name when values on a searchable surface are requested.
Geometric point merging has an inherent chance of failure that occurs
when a mesh contains valid distinct points that are closer together than
the supplied tolerance. It is beneficial to avoid such merging whenever
possible.
reconstructParMesh does not need explicit point merging any more. Points
may be duplicated temporarily when processor meshes are combined which
share points and edges but not faces. Ultimately, however,
reconstructParMesh reconstructs the entire mesh so everything eventually
gets face-connected and all point duplications get resolved.
fvMeshDistribute requires point-merging, as the entire mesh is not
constructed. However, since 5d4c8f5d, this process has been purely
topological and has not relied on any of the geometric merging processes
triggered by utilised code.
As such, all geometric point merging operations and tolerances have been
removed from these two implementations, as well as in lower level code
in faceCoupleInfo and polyMeshAdder. faceCoupleInfo has also had support
for face and edge splits removed as this was not being used. This change
will have improved the robustness of both reconstruction and
redistributuon and has greatly reduced the total amount of code
involved.
The only geometric tolerance-based matching still being performed by
either of these processes is as a result of coupled patch ordering in
fvMeshDistribute. It is possible that this is not necessary either
(though at present coupled patch ordering is certainly needed
elsewhere). This warrants further investigation.
Very occasionally a coupled patch contains two faces that are connected
by an edge, but which are numbered in opposite directions. Such faces
are not actually connected in a manifold sense. They just happen to
share two points. The edge in question should really be duplicated and
both should be considered to be part of the perimeter of the surface.
Walk patch ordering has been fixed so that it does not attempt to cross
edges such as these. This fixes a rare failure in snappyHexMesh.
Description
Multi-component Fickian and Fourier based temperature gradient heat flux
model laminar flow with optional Soret thermal diffusion of species.
Currently the diffusion coefficients are constant but temperature and
pressure dependency will be added.
The heat flux source is implemented as an implicit energy correction to the
temperature gradient based flux source. At convergence the energy
correction is 0.
Usage
\verbatim
laminar
{
model FickianFourier;
D (1e-5 2e-5 1e-5); // [m^2/s]
DT (1e-5 2e-5 1e-5); // [kg/m/s] Optional
}
\endverbatim
Description
Thixotropic viscosity momentum transport model based on the evolution of
the structural parameter \f$ \lambda \f$:
\f[
\frac{D\lambda}{Dt} = a(1 - \lambda)^b - c \lambda \dot{\gamma}^d
\f]
The viscosity is then calculated using the expression
\f[
\nu = \frac{\nu_{\infty}}{{1 - K \lambda}^2}
\f]
Where the parameter K is given by:
\f[
K = 1 - \sqrt{\frac{\nu_{\infty}}{\nu_{0}}}
\f]
Here:
\vartable
\lambda | structural parameter
a | model coefficient
b | model coefficient
c | model coefficient
d | model coefficient
\dot{\gamma} | stress rate [1/s]
\nu_{0} | limiting viscosity when \f$ \lambda = 1 \f$
\nu_{\infty} | limiting viscosity when \f$ \lambda = 0 \f$
\endvartable
Reference:
\verbatim
Barnes H A, 1997. Thixotropy - a review. J. Non-Newtonian Fluid
Mech 70, pp 1-33
\endverbatim
Description
Transforms the specified velocity field into a
cylindrical polar coordinate system or back to Cartesian.
Example of function object specification to convert the velocity field U
into cylindrical polar coordinates before averaging and returning the
average to Cartesian coordinates:
\verbatim
cartesianToCylindrical
{
type cylindrical;
libs ("libfieldFunctionObjects.so");
origin (0 0 0);
axis (0 0 1);
field U;
writeControl outputTime;
writeInterval 1;
}
#includeFunc fieldAverage(cylindrical(U))
cylindricalToCartesian
{
type cylindrical;
libs ("libfieldFunctionObjects.so");
origin (0 0 0);
axis (0 0 1);
field cylindrical(U)Mean;
toCartesian true;
result UMean;
writeControl outputTime;
writeInterval 1;
}
\endverbatim
This is particularly useful for cases with rotating regions, e.g. mixer
vessels with AMI.
See tutorials/incompressible/pimpleFoam/laminar/mixerVesselAMI2D
