A new constraint patch has been added which permits AMI coupling in
cyclic geometries. The coupling is repeated with different multiples of
the cyclic transformation in order to achieve a full correspondence.
This allows, for example, a cylindrical AMI interface to be used in a
sector of a rotational geometry.
The patch is used in a similar manner to cyclicAMI, except that it has
an additional entry, "transformPatch". This entry must name a coupled
patch. The transformation used to repeat the AMI coupling is taken from
this patch. For example, in system/blockMeshDict:
boundary
(
cyclic1
{
type cyclic;
neighbourPatch cyclic2;
faces ( ... );
}
cyclic2
{
type cyclic;
neighbourPatch cyclic1;
faces ( ... );
}
cyclicRepeatAMI1
{
type cyclicRepeatAMI;
neighbourPatch cyclicRepeatAM2;
transformPatch cyclic1;
faces ( ... );
}
cyclicRepeatAMI2
{
type cyclicRepeatAMI;
neighbourPatch cyclicRepeatAMI1;
transformPatch cyclic1;
faces ( ... );
}
// other patches ...
);
In this example, the transformation between cyclic1 and cyclic2 is used
to define the repetition used by the two cyclicRepeatAMI patches.
Whether cyclic1 or cyclic2 is listed as the transform patch is not
important.
A tutorial, incompressible/pimpleFoam/RAS/impeller, has been added to
demonstrate the functionality. This contains two repeating AMI pairs;
one cylindrical and one planar.
A significant amount of maintenance has been carried out on the AMI and
ACMI patches as part of this work. The AMI methods now return
dimensionless weights by default, which prevents ambiguity over the
units of the weight field during construction. Large amounts of
duplicate code have also been removed by deriving ACMI classes from
their AMI equivalents. The reporting and writing of AMI weights has also
been unified.
This work was supported by Dr Victoria Suponitsky, at General Fusion
For compatibility with all the mesh and related classes in OpenFOAM The 'normal'
function of the 'triangle', 'triFace' and 'face' classes now returns the unit
normal vector rather than the vector area which is now provided by the 'area'
function.
Without -fields specified mergeOrSplitBaffles now manipulates the mesh only and
with the -fields option also updates the fields corresponding to the mesh change.
In early versions of OpenFOAM the scalar limits were simple macro replacements and the
names were capitalized to indicate this. The scalar limits are now static
constants which is a huge improvement on the use of macros and for consistency
the names have been changed to camel-case to indicate this and improve
readability of the code:
GREAT -> great
ROOTGREAT -> rootGreat
VGREAT -> vGreat
ROOTVGREAT -> rootVGreat
SMALL -> small
ROOTSMALL -> rootSmall
VSMALL -> vSmall
ROOTVSMALL -> rootVSmall
The original capitalized are still currently supported but their use is
deprecated.
First run the surfaceFeatureExtract with the "closeness" option enabled in the
surfaceFeatureExtractDict to extract the surface closeness point field
// Out put the closeness of surface elements to other surface elements.
closeness yes;
Then enable cell sizing based on local surface closeness by specifying the
"internalCloseness" options in the foamyHexMeshDict e.g.
motionControl
{
defaultCellSize 4;
minimumCellSizeCoeff 0.1;
maxSmoothingIterations 100;
maxRefinementIterations 2;
shapeControlFunctions
{
geometry
{
type searchableSurfaceControl;
priority 1;
mode inside;
surfaceCellSizeFunction nonUniformField;
cellSizeCalculationType automatic;
curvature false;
curvatureFile dummy;
featureProximity false;
featureProximityFile dummy;
internalCloseness true;
internalClosenessFile geometry.internalPointCloseness;
internalClosenessCellSizeCoeff 25;
curvatureCellSizeCoeff 0;
maximumCellSizeCoeff 1;
cellSizeFunction uniform;
}
}
}
A patch can now be assigned to a baffle surface. This assignment will
take precedence over any face-zones.
surfaceConformation
{
locationInMesh (0 0 0);
geometryToConformTo
{
disk
{
featureMethod extractFeatures;
includedAngle 120;
meshableSide both; // <-- baffle
patchInfo
{
type wall;
inGroups (walls);
}
}
// ...
}
}
Foamy surface conformation entries have a "meshableSide" entry which
controls which side of the surface is to be meshed. Typically this is
set "inside" for boundaries and "both" for baffles. A sub-region's
default entry is now taken from it's parent, rather than a specific
value (it was "inside"). This is consistent with how other entries are
handled.
surfaceConformation
{
locationInMesh (0 0 0);
geometryToConformTo
{
baffle
{
featureMethod extractFeatures;
includedAngle 120;
meshableSide both; // <-- per-surface setting
regions
{
disk
{
meshableSide both; // <-- per-region setting*
// *in this example, this entry is not needed, as it
// is taken from the per-surface setting above
}
}
}
// ...
}
}
The new optional switch 'writeCyclicMatch' can be set to 'true' to enable the writing of
the cyclic match OBJ files; defaults to 'false'.
Patch contributed by Bruno Santos
Resolves patch request https://bugs.openfoam.org/view.php?id=2685
When an OpenFOAM simulation runs in parallel, the data for decomposed fields and
mesh(es) has historically been stored in multiple files within separate
directories for each processor. Processor directories are named 'processorN',
where N is the processor number.
This commit introduces an alternative "collated" file format where the data for
each decomposed field (and mesh) is collated into a single file, which is
written and read on the master processor. The files are stored in a single
directory named 'processors'.
The new format produces significantly fewer files - one per field, instead of N
per field. For large parallel cases, this avoids the restriction on the number
of open files imposed by the operating system limits.
The file writing can be threaded allowing the simulation to continue running
while the data is being written to file. NFS (Network File System) is not
needed when using the the collated format and additionally, there is an option
to run without NFS with the original uncollated approach, known as
"masterUncollated".
The controls for the file handling are in the OptimisationSwitches of
etc/controlDict:
OptimisationSwitches
{
...
//- Parallel IO file handler
// uncollated (default), collated or masterUncollated
fileHandler uncollated;
//- collated: thread buffer size for queued file writes.
// If set to 0 or not sufficient for the file size threading is not used.
// Default: 2e9
maxThreadFileBufferSize 2e9;
//- masterUncollated: non-blocking buffer size.
// If the file exceeds this buffer size scheduled transfer is used.
// Default: 2e9
maxMasterFileBufferSize 2e9;
}
When using the collated file handling, memory is allocated for the data in the
thread. maxThreadFileBufferSize sets the maximum size of memory in bytes that
is allocated. If the data exceeds this size, the write does not use threading.
When using the masterUncollated file handling, non-blocking MPI communication
requires a sufficiently large memory buffer on the master node.
maxMasterFileBufferSize sets the maximum size in bytes of the buffer. If the
data exceeds this size, the system uses scheduled communication.
The installation defaults for the fileHandler choice, maxThreadFileBufferSize
and maxMasterFileBufferSize (set in etc/controlDict) can be over-ridden within
the case controlDict file, like other parameters. Additionally the fileHandler
can be set by:
- the "-fileHandler" command line argument;
- a FOAM_FILEHANDLER environment variable.
A foamFormatConvert utility allows users to convert files between the collated
and uncollated formats, e.g.
mpirun -np 2 foamFormatConvert -parallel -fileHandler uncollated
An example case demonstrating the file handling methods is provided in:
$FOAM_TUTORIALS/IO/fileHandling
The work was undertaken by Mattijs Janssens, in collaboration with Henry Weller.
Updated the tetrahedron and triangle classes to use the barycentric
primitives. Removed duplicate code for generating random positions in
tets and tris, and fixed bug in tri random position.
now possible with level-sets as well as planes. Removed tetPoints class
as this wasn't really used anywhere except for the old tet-cutting
routines. Restored tetPointRef.H to be consistent with other primitive
shapes. Re-wrote tet-overlap mapping in terms of the new cutting.
except turbulence and lagrangian which will also be updated shortly.
For example in the nonNewtonianIcoFoam offsetCylinder tutorial the viscosity
model coefficients may be specified in the corresponding "<type>Coeffs"
sub-dictionary:
transportModel CrossPowerLaw;
CrossPowerLawCoeffs
{
nu0 [0 2 -1 0 0 0 0] 0.01;
nuInf [0 2 -1 0 0 0 0] 10;
m [0 0 1 0 0 0 0] 0.4;
n [0 0 0 0 0 0 0] 3;
}
BirdCarreauCoeffs
{
nu0 [0 2 -1 0 0 0 0] 1e-06;
nuInf [0 2 -1 0 0 0 0] 1e-06;
k [0 0 1 0 0 0 0] 0;
n [0 0 0 0 0 0 0] 1;
}
which allows a quick change between models, or using the simpler
transportModel CrossPowerLaw;
nu0 [0 2 -1 0 0 0 0] 0.01;
nuInf [0 2 -1 0 0 0 0] 10;
m [0 0 1 0 0 0 0] 0.4;
n [0 0 0 0 0 0 0] 3;
if quick switching between models is not required.
To support this more convenient parameter specification the inconsistent
specification of seedSampleSet in the streamLine and wallBoundedStreamLine
functionObjects had to be corrected from
// Seeding method.
seedSampleSet uniform; //cloud; //triSurfaceMeshPointSet;
uniformCoeffs
{
type uniform;
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
to the simpler
// Seeding method.
seedSampleSet
{
type uniform;
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
which also support the "<type>Coeffs" form
// Seeding method.
seedSampleSet
{
type uniform;
uniformCoeffs
{
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
}
By default snappyHexMesh writes files relating to the hex-splitting process into
the polyMesh directory: cellLevel level0Edge pointLevel surfaceIndex
but by setting the noRefinement flag:
writeFlags
(
noRefinement
.
.
.
);
these optional files which are generally not needed are not written.
If you run the three stages of snappyHexMesh separately or run a dynamic mesh
solver supporting refinement and unrefinement these files are needed
and "noRefinement" should not be set.
unless the blockMeshDict is in the polyMesh directory or the "-noClean" option
is specified.
This avoids problems running snappyHexMesh without first clearing files from
polyMesh which interfere with the operation of snappyHexMesh.
