by introducing rational base-classes rather than using the hideous
'switch' statement. Further rationalization of the cell-selection
mechanism will be implemented via an appropriate class hierarchy to
replace the remaining 'switch' statement.
Mesh-motion is currently handled very inefficiently for cellSets and not
at all for inter-region coupling. The former will be improved when the
cell-selection classes are written and the latter by making the
meshToMesh class a MeshObject after it has been corrected for mapFields.
fvOptions does not have the appropriate structure to support MRF as it
is based on option selection by user-specified fields whereas MRF MUST
be applied to all velocity fields in the particular solver. A
consequence of the particular design choices in fvOptions made it
difficult to support MRF for multiphase and it is easier to support
frame-related and field related options separately.
Currently the MRF functionality provided supports only rotations but
the structure will be generalized to support other frame motions
including linear acceleration, SRF rotation and 6DoF which will be
run-time selectable.
SIMPLEC (SIMPLE-consistent) is selected by setting "consistent" option true/yes:
SIMPLE
{
nNonOrthogonalCorrectors 0;
consistent yes;
}
which relaxes the pressure in a "consistent" manner and additional
relaxation of the pressure is not generally necessary. In addition
convergence of the p-U system is better and reliable with less
aggressive relaxation of the momentum equation, e.g. for the motorbike
tutorial:
relaxationFactors
{
equations
{
U 0.9;
k 0.7;
omega 0.7;
}
}
The cost per iteration is marginally higher but the convergence rate is
better so the number of iterations can be reduced.
The SIMPLEC algorithm also provides benefit for cases with large
body-forces, e.g. SRF, see tutorials/incompressible/SRFSimpleFoam/mixer
and feature request http://www.openfoam.org/mantisbt/view.php?id=1714
Example usage:
SBM
{
type tabulatedAccelerationSource;
active true;
selectionMode all;
tabulatedAccelerationSourceCoeffs
{
timeDataFileName "constant/acceleration.dat";
}
}
Where the file constant/acceleration.dat contains a list of tuples
containing time and a vector of the linear acceleration, angular
velocity and angular acceleration e.g.
100
(
(0 ((0 0 0) (0 0 0) (0 0 0)))
(0.001 ((-0.0001 0 4e-05) (5e-5 -0.0002 -3e-8) (0.24 -0.8 -1e-4)))
.
.
.
)
This had been used in functionObjects:
Info(log)<< "messages" << data << ....
in which it is not at all clear what the "log" argument does whereas
if (log) Info<< "messages" << data << ....
is totally clear and more efficient.
On 32bit OSs long is not unambiguously int32_t (or int64_t) causing
problems for IO operator resolution. This problem is avoided by
explicitly defining the following operators:
