e.g. the motion of two counter-rotating AMI regions could be defined:
dynamicFvMesh dynamicMotionSolverListFvMesh;
solvers
(
rotor1
{
solver solidBody;
cellZone rotor1;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega 6.2832; // rad/s
}
}
rotor2
{
solver solidBody;
cellZone rotor2;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega -6.2832; // rad/s
}
}
);
Any combination of motion solvers may be selected but there is no special
handling of motion interaction; the motions are applied sequentially and
potentially cumulatively.
To support this new general framework the solidBodyMotionFvMesh and
multiSolidBodyMotionFvMesh dynamicFvMeshes have been converted into the
corresponding motionSolvers solidBody and multiSolidBody and the tutorials
updated to reflect this change e.g. the motion in the mixerVesselAMI2D tutorial
is now defined thus:
dynamicFvMesh dynamicMotionSolverFvMesh;
solver solidBody;
solidBodyCoeffs
{
cellZone rotor;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega 6.2832; // rad/s
}
}
- only occurs in combination with distributedTriSurfaceMesh in snappy.
- workaround similar to that previously used for surfaceRedistributePar
(issue #60).
Minor adjustment of incompressible motorBike tutorial to detect use of
distributedTriSurfaceMesh.
- In the corner case with few faces or points, the normal List I/O
results in a compact list representation.
This is less than desirable for external programs with simple
line-based parsers.
- Write exactly the following
*Faces*
// Patch: <word-Region> <word-Patch>
<int-nFaces>
(
<int-faceSize>(<int> .. <int>)
...
)
*Points*
// Patch: <word-Region> <word-Patch>
<int-nPoints>
(
(<float-x> <float-y> <float-z>)
...
)
STYLE: only use serial form of createExternalCoupledPatchGeometry in tutorial
- less confusing for the user, who wonders why it is being done twice.
New functionality contributed by Mattijs Janssens:
- new edge projection: projectCurve for use with new geometry
'searchableCurve'
- new tutorial 'pipe'
- naming of vertices and blocks (see pipe tutorial). Including back
substitution for error messages.
- Cleanup/centralize handling of -decomposeParDict by relocating
common code into argList. Ensures that all processes receive
identical information about the -decomposeParDict opton.
- Only use alternative decomposeParDict for simpleFoam/motorBike
tutorial so that this will be included in the test loop for snappy.
- Added Mattijs' fix for surfaceRedistributePar.
