The population balance model considers dilatation originating from density
change and mass transfer via source terms describing nucleation as well as
"drift" of the size distribution to smaller or larger sizes. Numerically, the
treatment does not necessarily equal the total dilatation, hence a correction is
introduced to ensure boundedness of the size group fractions.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
and VTT Technical Research Centre of Finland Ltd.
The refinement cell set is now generated directly using boxToCell. The
mesh now uses cyclic, rather than cyclicAMI, patches so that propagation
of the refinement across the coupling can be tested. Field files have
been simplified by using #includeEtc to set constraints. A best practice
velocity/pressure specification has been set for the outlet boundary.
Unused fields and settings have been removed.
New interpolation and snGrad schemes to help stabilise multiphaseEulerFoam runs
on poor meshes by reverting to a bounded form when the phase-fraction
corresponding to the phase of the field argument is less than 1e-3. If this
approach proves effective and it would be useful to adjust the phase-fraction
limit it could be made a user input.
Class
Foam::phaseStabilised
Description
Phase-stabilised interpolation scheme
which applies upwind to the faces at which the upwind phase-fraction is less
than 1e-3.
Class
Foam::fv::phaseStabilisedSnGrad
Description
snGrad scheme with phase-fraction limited non-orthogonal correction.
When the phase-fraction is less than 1e-3 the non-orthogonal correction is
set to 0.
Example specification in fvSchemes:
gradSchemes
{
default Gauss linear;
limited cellLimited Gauss linear 1;
}
divSchemes
{
default none;
.
.
.
"div\(alphaRhoPhi.*,U.*\)" Gauss phaseStabilised linearUpwindV limited;
"div\(phi.*,U.*\)" Gauss phaseStabilised linearUpwindV limited;
"div\(alphaRhoPhi.*,(h|e).*\)" Gauss phaseStabilised limitedLinear 1;
"div\(alphaRhoPhi.*,K.*\)" Gauss phaseStabilised limitedLinear 1;
"div\(alphaRhoPhi.*,\(p\|thermo:rho.*\)\)" Gauss phaseStabilised limitedLinear 1;
.
.
.
}
laplacianSchemes
{
default Gauss linear limited corrected 0.33;
phaseStabilised Gauss linear phaseStabilised limited corrected 0.33;
laplacian(((alpha.air*thermo:rho.air)*nuEff.air),U.air) $phaseStabilised;
laplacian(((alpha.water*thermo:rho.water)*nuEff.water),U.water) $phaseStabilised;
laplacian((alpha.air*alphaEff),h.air) $phaseStabilised;
laplacian((alpha.water*alphaEff),e.water) $phaseStabilised;
}
PrimitivePatch is a geometry engine. Is not used, and is not designed to
be used, as an abstract interface. That function is left to
PrimitivePatch's immediate derivations, such as polyPatch and
MeshedSurface.
This change means this function is determining the sequence in which
points are plotted topologically. This makes it possible to plot a layer
average along a pipe that goes through many changes of direction.
Previously, the function determined the order by means of a geometric
sort in the plot direction. This only worked when the layers were
perpendicular to one of the coordinate axes.
This is a simple function that provides a convenient way for a user to
call fvc::reconstruct for the purposes of post-processing flux fields;
e.g., to construct a cell velocity from a face flux.
It can be used to generate output during a run by adding the following
settings to a case's controlDict:
functions
{
#includeFunc reconstruct(phi)
}
Or it can be executed as a postProcessing step by calling:
postProcess -func "reconstruct(phi)"
epsilonm is obtained by combining epsilon.gas and epsilon.liquid in a two-phase
system, each of which will apply the epsilonWallFunction at walls; the
epsilonmWallFunction propagates the resulting wall epsilonm into the near-wall
cells.
If the 0/epsilonm file is provided the epsilonmWallFunction should be specified
for walls, if the 0/epsilonm file is not provided it will be generated
automatically and the epsilonmWallFunction applied to walls for which the
epsilonWallFunction is specified in the epsilon.liquid file.
Rather than rely on the MRF rotation the effect of acceleration due to flow
curvature on the dispersed is now handled directly using the Ud.grad(Ud) term
derived from the phase momentum equation. This means that any flow curvature
from bulk rotation to recirulation zones now affect the separation of the
dispersed phase from the continuous phase in a physical manner.
fvMesh::update() now executes at the beginning of the time-step, before time is
incremented and handles topology change, mesh to mesh mapping and redistribution
without point motion. Following each of these mesh changes fields are mapped
from the previous mesh state to new mesh state in a conservative manner. These
mesh changes not occur at most once per time-step.
fvMesh::move() is executed after time is incremented and handles point motion
mesh morphing during the time-step in an Arbitrary Lagrangian Eulerian approach
requiring the mesh motion flux to match the cell volume change. fvMesh::move()
can be called any number of times during the time-step to allow iterative update
of the coupling between the mesh motion and field solution.
With fvMeshTopoChangers::meshToMesh it is now possible to map the solution to a
specified sequence of pre-generated meshes at run-time to support arbitrary mesh
changes, refinements, un-refinements, changes in region topology, geometry,
etc. Additionally mesh-motion between the sequence of meshes is supported to
allow for e.g. piston and valve motion in engines.
The tutorials/incompressible/pimpleFoam/laminar/movingCone case has been updated
to provide a demonstration of the advantages of this run-time mesh-mapping by
mapping to meshes that are finer behind the cone and coarser in front of the
cone as the cone approaches the end of the domain, thus maintaining good
resolution while avoiding excessive cell aspect ratio as the mesh is squeezed.
The dynamicMeshDict for the movingCone case is;
mover
{
type motionSolver;
libs ("libfvMeshMovers.so" "libfvMotionSolvers.so");
motionSolver velocityComponentLaplacian;
component x;
diffusivity directional (1 200 0);
}
topoChanger
{
type meshToMesh;
libs ("libmeshToMeshTopoChanger.so");
times (0.0015 0.003);
timeDelta 1e-6;
}
which lists the mesh mapping times 0.0015s 0.003s and meshes for these times in
directories constant/meshToMesh_0.0015 and constant/meshToMesh_0.003 are
generated in the Allrun script before the pimpleFoam run:
runApplication -a blockMesh -dict blockMeshDict.2
rm -rf constant/meshToMesh_0.0015
mkdir constant/meshToMesh_0.0015
mv constant/polyMesh constant/meshToMesh_0.0015
runApplication -a blockMesh -dict blockMeshDict.3
rm -rf constant/meshToMesh_0.003
mkdir constant/meshToMesh_0.003
mv constant/polyMesh constant/meshToMesh_0.003
runApplication -a blockMesh -dict blockMeshDict.1
runApplication $application
Note: This functionality is experimental and has only undergone basic testing.
It is likely that it does not yet work with all functionObject, fvModels
etc. which will need updating to support this form of mesh topology change.
This joint allows two bodies to rotate relative to each other at a
specified speed. The relative motion is completely specified, so this
joint has zero degrees of freedom.
It could be used, for example, to attach a rotating propeller to a
moving ship:
bodies
{
hull
{
...
}
propeller
{
type rigidBody;
// Dynamic properties
mass ...;
centreOfMass ...;
inertia ...;
// The propeller is connected to the hull
parent hull;
// The position relative to the hull
transform (1 0 0 0 1 0 0 0 1) (20 0 0);
// Rotation settings
joint
{
type rotating;
omega (6 0 0);
}
}
}
The near wall distances calculated for use in wall functions and the
corrections applied to near wall cells as part of the meshWave
wall/patch distance method have been made consistent across processor
and cyclic boundaries.
The extent to which these corrections are performed in the meshWave
method is now controllable by an nCorrectors entry. This defaults to 2,
which produces a result rougly equivalent to the previous correction
procedure. A higher level of correction could be specified as follows,
in system/fvSchemes:
wallDist
{
method meshWave;
nCorrectors 3;
}
Corrections replace basic cell-centre-face-centre distances with more
accurate cell-centre-face-polygon calculations in which all the points
and edges of the wall face are taken into account. The number of
correctors represents the number of layers of cells that these
corrections propagate into the mesh from the wall faces in question.
Note that correctors are expensive, and returns diminish as the number
of corrections increase, as the error in the basic calculation reduces
with distance from the wall faces. It is unlikely that more than 2 or
3 correctors would ever be warranted. Indeed, this control is
potentially more useful in reducing the number of corrections to 1 or 0
in order to reduce the computational expense in dynamic mesh cases where
distances are being constantly recomputed.
so that the input is now dictionary rather than list of dictionaries which
provides support for dictionary substitutions within the motionSolver
sub-dictionaries and also simplifies lookup of specific motionSolvers within the
list. For example the dynamicMeshDict for the floatingObject case with a second
floating object would be:
mover
{
type motionSolver;
libs ("libfvMeshMovers.so" "librigidBodyMeshMotion.so");
motionSolver motionSolverList;
solvers
{
floatingObject
{
motionSolver rigidBodyMotion;
report on;
solver
{
type Newmark;
}
accelerationRelaxation 0.7;
bodies
{
floatingObject
{
type cuboid;
parent root;
// Cuboid dimensions
Lx 0.3;
Ly 0.2;
Lz 0.5;
// Density of the cuboid
rho 500;
// Cuboid mass
mass #calc "$rho*$Lx*$Ly*$Lz";
L ($Lx $Ly $Lz);
centreOfMass (0 0 0.25);
transform (1 0 0 0 1 0 0 0 1) (0.5 0.45 0.1);
joint
{
type composite;
joints
(
{
type Py;
}
{
type Ry;
}
);
}
patches (floatingObject);
innerDistance 0.05;
outerDistance 0.35;
}
}
}
anotherFloatingObject
{
.
.
.
}
}
}
This new mapping structure is designed to support run-time mesh-to-mesh mapping
to allow arbitrary changes to the mesh structure, for example during extreme
motion requiring significant topology change including region disconnection etc.
The polyTopoChangeMap is the map specifically relating to polyMesh topological
changes generated by polyTopoChange and used to update and map mesh related
types and fields following the topo-change.
This is a map data structure rather than a class or function which performs the
mapping operation so polyMeshDistributionMap is more logical and comprehensible
than mapDistributePolyMesh.
