The method used to calculate area overlaps between coupled AMI patches
has been made run-time selectable from the polyPatch dictionary. This
has primarily been done to facilitate the selection of the new swept AMI
method. The selection can be made within the constant/polyMesh/boundary
file as follows:
AMI1
{
type cyclicAMI;
inGroups 2(cyclicAMI rotating);
nFaces 524;
startFace 37176;
matchTolerance 0.0001;
transform unknown;
neighbourPatch AMI2;
method sweptFaceAreaWeightAMI; // <-- new entry
}
AMI2
{
type cyclicAMI;
inGroups 2(cyclicAMI rotating);
nFaces 524;
startFace 37700;
matchTolerance 0.0001;
transform unknown;
neighbourPatch AMI1;
method sweptFaceAreaWeightAMI; // <-- new entry
}
This can also be done within the patch specification section of the
blockMeshDict, or within a createBafflesDict.
The default remains the faceAreaWeightAMI method.
This change tests all edges when breaking strings, not just those
connected to collapsing cells. In rare cases a cell can collapse despite
none of it's connected edges being marked as collapsing, because enough
of it's points collapse together via other edges.
Another exception has been added to globalIndexAndTransform to prevent
transformations being generated from coupled patch pairs marked with
coincident-full-match transformations. Foamy generates such patches, and
the faces on them at intermediate stages of meshing can be degenerate,
making the calculation of transformations unreliable. This change
enforces the definition that coincident-full-match patch pairs are not
transformed.
In the event that matching centroids across a coupled patch pair fails,
we fall back to matching the face point average. The latter can be
obtained more reliably on degenerate faces as the calculation does not
involve division by the face area.
This fallback was already implemented as part of processorPolyPatch.
This change also applies it to the faceCoupleInfo class used by
reconstructParMesh.
The continuation line are denoted by the \\ characters at the end of the
previous line e.g.
\table
Property | Description | Required | Default value
setAverage | Switch to activate setting of average value | no | false
perturb | Perturb points for regular geometries | no | 1e-5
fieldTableName | Alternative field name to sample | no| this field name
mapMethod | Type of mapping | no | planarInterpolation
offset | Offset to mapped values | no | Zero
dataDir | Top-level directory of the points and field data \\
| no | constant/boundaryData/\<patch name\>
points | Path including name of points file relative to dataDir \\
| no | points
sample | Name of the sub-directory in the time directories \\
containing the fields | no | ""
\endtable
Description
This boundary conditions interpolates the values from a set of supplied
points in space and time.
By default the data files should be provide in
constant/boundaryData/\<patch name\>/ directory:
- points : pointField of locations
- \<time\>/\<field\> : field of values at time \<time\>
Alternatively the names and locations of the points and field files may be
specified explicitly via the optional dictionary entries:
- dataDir \<optional top-level directory of the points and field data>;
- points \<optional path including name of points file relative to
dataDir\>;
- sample \<optional name of the sub-directory in the time directories
containing the fields\>;
This is particularly useful when mapping data from another case for which
the \c sample \c functionObject is used to obtain the patch field data for
mapping.
For example to specify that the point and field data should be mapped from
<source case name> the patch boundary condition would be written
<patch name>
{
type timeVaryingMappedFixedValue;
dataDir "../<source case name>/postProcessing/sample";
points "0/<sample name>/faceCentres";
sample <sample name>;
}
In the above the source case directory is referred to relative to the current
case but the file and directory names are expanded so that environment variables
may be used.
This method projects the source patch to the target using the point
normals. The projection fills space, which results in target weights
that correctly sum to unity. A source patch face can still project onto
an area larger or smaller than the face, so the source weights do not
(in general) sum to unity as a result of this method.
This has not been made the default AMI method. Further investigation is
needed to asses the benefits of this sort of projection.
The maximum walk angle determines the angle at which the face-face walk
stops. For some methods, this prevents calculation of overlaps on pairs
of faces which do not project on to each other. Derived AMI methods can
now override this angle as appropriate for their projection procedure.
The patch magSf calculation has been changed so that it uses the same
triangulation as the overlap algorithm. This improves consistency and
means that for exactly conforming patches (typically before any mesh
motion) the weights do not require normalisation.
In this version of compressibleInterFoam separate stress models (laminar,
non-Newtonian, LES or RAS) are instantiated for each of the two phases allowing
for completely different modeling for the phases.
e.g. in the climbingRod tutorial case provided a Newtonian laminar model is
instantiated for the air and a Maxwell non-Newtonian model is instantiated for
the viscoelastic liquid. To stabilize the Maxwell model in regions where the
liquid phase-fraction is 0 the new symmTensorPhaseLimitStabilization fvOption is
applied.
Other phase stress modeling combinations are also possible, e.g. the air may be
turbulent but the liquid laminar and an RAS or LES model applied to the air
only. However, to stabilize this combination a suitable fvOption would need to
be applied to the turbulence properties where the air phase-fraction is 0.
Henry G. Weller, Chris Greenshields
CFD Direct Ltd.
so the write thread does not have to do any parallel communication. This avoids
the bugs in the threading support in OpenMPI.
Patch contributed by Mattijs Janssens
Resolves bug-report https://bugs.openfoam.org/view.php?id=2669
This ensures that the fvOptions are constructed for the -postProcessing option
so that functionObjects which process fvOption data operate correctly in this
mode.
To unsure fvOptions are instantiated for post-processing createFvOptions.H must
be included in createFields.H rather than in the solver directly.
Resolves bug-report https://bugs.openfoam.org/view.php?id=2733
The restraints generate either joint-local (tau) or global (fx) forces.
At the moment they all generate the latter. This change corrects three
of the four restraints so that the forces are in the gobal coordinate
system and not the local coordinate system of the body.
The problem with this is that the forward dynamics code then transforms
most of the forces back to the body local coordinate system. A better
solution would be to associate restraints which are more sensibly
defined in a local frame with the joints instead of the bodies, and
return the forces as part of the tau variable.
Corrected a few issues with the utilisation of the tracking within the
nearWallFields function object. The tracking is now done over a
displacement from the initial location, which prevents trying to track
to a location outside the mesh when the patch face is warped and the
centre lies outside the tracking decomposition. Also fixed the end
criteria so that it does not suffer from round off error in the step
fraction.
The upshot of these changes is that the faces on which the near wall
cells were not being set are now being set properly, and uninitialised
data is no longer being written out.
