All wall functions now operate collaboratively, obtaining the Cmu, kappa and E
coefficients and yPlusLam from the nutWallFunction base class. Now these
optional inputs need only be specified in the nut boundary condition with the k,
epsilon, omega, v2 and f wall functions obtaining these values from there. This
is much simpler to specify and avoids inconsistencies in the operation of the
wall functions for the different turbulence fields.
The code has also been rationalised and simplified avoiding unnecessary code
and duplication.
The volumeFractionSource represents the effect of a reduction in the
volume of the domain due to the presence of a stationary phase, most
likely a solid porous media. It only represents the dynamic effects
associated with the reduction in volume; it does not does not model
loss, drag or heat transfer. Separate models (e.g., the existing
porosity models) will be necessary to represent these effects. An
example usage, in system/fvOptions, is as follows:
volumeFraction
{
type volumeFractionSource;
phase solid;
phi phi;
rho rho;
U U;
fields (rho U e);
}
The volume fraction will be read from constant/alpha.<phase>, and must
be generated in advance using setFields or a function object. Note that
the names of the flux, density (if compressible) and velocity must all
be specified. Every field for which a transport equation is solved
should also be specified in the "fields" entry.
The solidEquilibriumEnergySource adds the thermal inertia and diffusive
characteristics of a stationary solid phase to the energy equation of
the fluid, assuming that the two phases are in thermal equilibrium. An
example usage is as follows:
solidEqulibriumEnergy
{
type solidEqulibriumEnergySource;
phase solid;
field e;
}
This will read the volume fraction in the same way as the
volumeFractionSource option. In addition, thermal properties of the
solid will be constructed from settings in
system/thermophysicalProperties.<phase>.
Two tutorials have been added, demonstrating use of these options in
both incompressible and compressible simulations. These are
incompressible/pimpleFoam/laminar/blockedChannel and
compressible/rhoPimpleFoam/laminar/blockedChannel.
Implementation of the Giesekus model for visco-elasticity, derived from the new
generalised form of the Maxwell model which now support additional sources.
Giesekus, H., 1982.
A simple constitutive equation for polymer fluids based on the
concept of deformation-dependent tensional mobility.
J. Non-Newton. Fluid. 11, 69–109.
This implementation is instantiated for incompressible, compressible and VoF
two-phase flow.
For most steady cases simpleFoam is likely to converge faster than pimpleFoam
with LTS but this capability may be useful for testing meshes, BCs etc. for more
complex solver for which SIMPLE is not stable and LTS is provided instead.
The writeEntry form is now defined and used consistently throughout OpenFOAM
making it easier to use and extend, particularly to support binary IO of complex
dictionary entries.
Now for transient simulations "Final" solver settings are required for ALL
equations providing consistency between the solution of velocity, energy,
composition and radiation properties.
However "Final" relaxation factors are no longer required for fields or
equations and if not present the standard value for the variable will be
applied. Given that relaxation factors other than 1 are rarely required for
transient runs and hence the same for all iterations including the final one
this approach provide simpler input while still providing the flexibility to
specify a different value for the final iteration if required. For steady cases
it is usual to execute just 1 outer iteration per time-step for which the
standard relaxation factors are appropriate, and if more than one iteration is
executed it is common to use the same factors for both. In the unlikely event
of requiring different relaxation factors for the final iteration this is still
possible to specify via the now optional "Final" specification.
snappyHexMesh now generates a face-zone for the AMI-s, and createBaffles
and mergeOrSplitPoints -split are used to create the patches. Before,
snappy generated AMI patches directly, which were then converted to
AMI-s with createPatch.
This way, the AMI-s match exactly at the start of the simulation. For
more complicated cases that may be derived from this tutorial, this
could be important.
The sampled sets have been renamed in a more explicit and consistent
manner, and two new ones have also been added. The available sets are as
follows:
arcUniform: Uniform samples along an arc. Replaces "circle", and
adds the ability to sample along only a part of the circle's
circumference. Example:
{
type arcUniform;
centre (0.95 0 0.25);
normal (1 0 0);
radial (0 0 0.25);
startAngle -1.57079633;
endAngle 0.52359878;
nPoints 200;
axis x;
}
boundaryPoints: Specified point samples associated with a subset of
the boundary. Replaces "patchCloud". Example:
{
type boundaryPoints;
patches (inlet1 inlet2);
points ((0 -0.05 0.05) (0 -0.05 0.1) (0 -0.05 0.15));
maxDistance 0.01;
axis x;
}
boundaryRandom: Random samples within a subset of the boundary.
Replaces "patchSeed", but changes the behaviour to be entirely
random. It does not seed the boundary face centres first. Example:
{
type boundaryRandom;
patches (inlet1 inlet2);
nPoints 1000;
axis x;
}
boxUniform: Uniform grid of samples within a axis-aligned box.
Replaces "array". Example:
{
type boxUniform;
box (0.95 0 0.25) (1.2 0.25 0.5);
nPoints (2 4 6);
axis x;
}
circleRandom: Random samples within a circle. New. Example:
{
type circleRandom;
centre (0.95 0 0.25);
normal (1 0 0);
radius 0.25;
nPoints 200;
axis x;
}
lineFace: Face-intersections along a line. Replaces "face". Example:
{
type lineFace;
start (0.6 0.6 0.5);
end (0.6 -0.3 -0.1);
axis x;
}
lineCell: Cell-samples along a line at the mid-points in-between
face-intersections. Replaces "midPoint". Example:
{
type lineCell;
start (0.5 0.6 0.5);
end (0.5 -0.3 -0.1);
axis x;
}
lineCellFace: Combination of "lineFace" and "lineCell". Replaces
"midPointAndFace". Example:
{
type lineCellFace;
start (0.55 0.6 0.5);
end (0.55 -0.3 -0.1);
axis x;
}
lineUniform: Uniform samples along a line. Replaces "uniform".
Example:
{
type lineUniform;
start (0.65 0.3 0.3);
end (0.65 -0.3 -0.1);
nPoints 200;
axis x;
}
points: Specified points. Replaces "cloud" when the ordered flag is
false, and "polyLine" when the ordered flag is true. Example:
{
type points;
points ((0 -0.05 0.05) (0 -0.05 0.1) (0 -0.05 0.15));
ordered yes;
axis x;
}
sphereRandom: Random samples within a sphere. New. Example:
{
type sphereRandom;
centre (0.95 0 0.25);
radius 0.25;
nPoints 200;
axis x;
}
triSurfaceMesh: Samples from all the points of a triSurfaceMesh.
Replaces "triSurfaceMeshPointSet". Example:
{
type triSurfaceMesh;
surface "surface.stl";
axis x;
}
The headers have also had documentation added. Example usage and a
description of the control parameters now exists for all sets.
In addition, a number of the algorithms which generate the sets have
been refactored or rewritten. This was done either to take advantage of
the recent changes to random number generation, or to remove ad-hoc
fixes that were made unnecessary by the barycentric tracking algorithm.
A new constraint patch has been added which permits AMI coupling in
cyclic geometries. The coupling is repeated with different multiples of
the cyclic transformation in order to achieve a full correspondence.
This allows, for example, a cylindrical AMI interface to be used in a
sector of a rotational geometry.
The patch is used in a similar manner to cyclicAMI, except that it has
an additional entry, "transformPatch". This entry must name a coupled
patch. The transformation used to repeat the AMI coupling is taken from
this patch. For example, in system/blockMeshDict:
boundary
(
cyclic1
{
type cyclic;
neighbourPatch cyclic2;
faces ( ... );
}
cyclic2
{
type cyclic;
neighbourPatch cyclic1;
faces ( ... );
}
cyclicRepeatAMI1
{
type cyclicRepeatAMI;
neighbourPatch cyclicRepeatAM2;
transformPatch cyclic1;
faces ( ... );
}
cyclicRepeatAMI2
{
type cyclicRepeatAMI;
neighbourPatch cyclicRepeatAMI1;
transformPatch cyclic1;
faces ( ... );
}
// other patches ...
);
In this example, the transformation between cyclic1 and cyclic2 is used
to define the repetition used by the two cyclicRepeatAMI patches.
Whether cyclic1 or cyclic2 is listed as the transform patch is not
important.
A tutorial, incompressible/pimpleFoam/RAS/impeller, has been added to
demonstrate the functionality. This contains two repeating AMI pairs;
one cylindrical and one planar.
A significant amount of maintenance has been carried out on the AMI and
ACMI patches as part of this work. The AMI methods now return
dimensionless weights by default, which prevents ambiguity over the
units of the weight field during construction. Large amounts of
duplicate code have also been removed by deriving ACMI classes from
their AMI equivalents. The reporting and writing of AMI weights has also
been unified.
This work was supported by Dr Victoria Suponitsky, at General Fusion
Streamlines can now be tracked in both directions from the set of
initial locations. The keyword controlling this behaviour is
"direction", which can be set to "forward", "backward" or "both".
This new keyword superseeds the "trackForward" entry, which has been
retained for backwards compatibility.
Replaced the ad hoc geometric mean blending with the more physical wall distance
Reynolds number blending function.
Additionally the part of the production term active for y+ < 11.6 has been
reinstated.
Some tutorials have had Allrun scripts added in order to run setFields,
which was previously omitted. Others have had nonuniform field files in
the 0 directory replaced by uniform files with .orig extensions.
These BCs blend between typical inflow and outflow conditions based on the
velocity orientation.
airFoil2D tutorial updated to demonstrate these new BCs.
