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.
Moving mesh cases running with 2nd-order ddt schemes can now run with
re-distribution. This does not include support for topology change including
mesh refinement which will require special complex handling for 2nd-order time
schemes.
Added solid particle coalescence model by Adachi, Stuart and Fokkink
(1994), solid particle breakage model by Kusters (1991) and spherical
particle lift force model by Saffman-Mei (1992).
Patch contributed by Kasper Gram Bilde and Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
A single transform method has been written to govern meshWave transfers
through transformed interfaces. This allows the transformer class to
take care of the different types of transform (e.g., displacement vs
positions), rather than having the waved data do it manually. It also
simplifies the creation of data classes and removes a large number of
functions that do nothing.
Propagation through AMI interfaces and the transformation of wall
normals through has also been corrected.
fvMesh is no longer derived from fvSchemes and fvSolution, these are now
demand-driven and accessed by the member functions schemes() and solution()
respectively. This means that the system/fvSchemes and system/fvSolution files
are no longer required during fvMesh constructions simplifying the mesh
generation and manipulation phase; theses files are read on the first call of
their access functions.
The fvSchemes member function names have also been simplified taking advantage
of the context in which they are called, for example
mesh.ddtScheme(fieldName) -> mesh.schemes().ddt(fieldName)
This method of igniting is easier to control than a heat-source based
method. A suitable temperature at which the reaction will take is
typically fairly easy to estimate, whilst determining a heat source
value which achieves the same effect is difficult and is often requires
trial and error.
The new fractional control of value constraints has permitted the use of
fixedTemperatureConstraint in this way; both because it allows for
ramping and for limiting the duration over which the constraint is
applied.
An optional Function1 can now be supplied to a fixedValueConstraint
which controls what proportion of the constraint is applied. This can be
used to ramp, pulse, or limit the duration of the constraint. For
example, ramping up of the constraint could be specified as follows:
scalarSource
{
type fixedValueConstraint;
selectionMode points;
points ((0 0.1 0));
fieldValues
{
s 1;
}
fraction
{
type ramp;
duration 0.1;
}
}
Description
A topoSetSource to select faces based on cell centres inside a rotated
and/or skewed box.
The box can be defined with an origin and three vectors; i, j, and k. The
origin is one corner of the box, and the vectors are the edges connected to
that corner.
For example, the following defines a box rotated 45 degrees around the
z-axis, with width and depth of 0.2, height of 200, and with a bottom left
corner at (0.4 0.4 -100):
\verbatim
origin (0.4 0.4 -100);
i (0.141421 0.141421 0);
j (-0.141421 0.141421 0);
k (0 0 200);
\endverbatim
Alternatively, the box can be defined using a non-rotated box and details
of how it should be rotated. This syntax is triggered by the presence of
the keyword "box". A standard bounding box is supplied, along with a centre
of rotation and two vectors, n1 and n2. The rotation is taken to be that
which transforms n1 onto n2.
The above example can be equivalently specified in this alternative form as
follows:
\verbatim
box (0.4 0.4 -100) (0.6 0.6 100);
centre (0.4 0.4 0);
n1 (1 0 0);
n2 (1 1 0);
\endverbatim
This required changing the formulation of the relative velocity in terms of a
scalar velocity coefficient Vc rather than the velocity V0 such that
V0 = Vc*g
where g is the acceleration due to gravity. With MRF rotation
V0 = Vc*(g + <MRF centrifugal acceleration>)
The template parameters were only ever polyBoundaryMesh and
processorPolyPatch. Un-templating makes mainteance and bug-fixing
quicker as it means minor modifications no longer cause a full rebuild
of OpenFOAM.
The subtract option in mapFieldsPar was not implemented correctly and the
significant complexity in meshToMesh required to support it creates an
unwarranted maintenance overhead. The equivalent functionality is now provided
by the more flexible, convenient and simpler subtract functionObject.
It is not clear for what cases the minVol control is useful or necessary and for
some cases it causes problems with snapping and layer addition if not set to a
sufficiently small value.
This means the field gets decomposed and reconstructed in the same way
as any other point field, and prevents issues with restart of cases
which feature both mesh motion and topology change.
boundaryProcAddressing has been removed. This has not been needed for a
long time. decomposePar has been optimised for mininum IO, rather than
minimum memory usage. decomposePar has also been corrected so that it
can decompose sequences of time-varying meshes.
