gcc-13 has new code checking and warning mechanisms which are useful but not
entirely robust and produce many false positives, particularly with respect to
local references:
warning: possibly dangling reference to a temporary
This commit resolves many of the new warning messages but the above false
warnings remain. It is possible to switch off this warning but as it also
provides some useful checks it is currently left on.
The timeName() function simply returns the dimensionedScalar::name() which holds
the user-time name of the current time and now that timeName() is no longer
virtual the dimensionedScalar::name() can be called directly. The timeName()
function implementation is maintained for backward-compatibility.
This reduces duplication and inconsistency between the List, Field, Map,
and PtrList variants. It also allows for future extension to other
container types such as DynamicList.
Poly patches should not hold non-uniform physical data that needs
mapping on mesh changes (decomposition, reconstruction, topology change,
etc ...). They should only hold uniform data that can be user-specified,
or non-uniform data that can be constructed on the fly from the poly
mesh.
With the recent changes to mappedPatchBase and extrudeToRegionMesh, this
has now been consistenly enforced, and a number of incomplete
implementations of poly patch mapping have therefore been removed.
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.
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 FOAM file format has not changed from version 2.0 in many years and so there
is no longer a need for the 'version' entry in the FoamFile header to be
required and to reduce unnecessary clutter it is now optional, defaulting to the
current file format 2.0.
The calculation and input/output of transformations has been rewritten
for all coupled patches. This replaces multiple duplicated, inconsistent
and incomplete implementations of transformation handling which were
spread across the different coupled patch types.
Transformations are now calculated or specified once, typically during
mesh construction or manipulation, and are written out with the boundary
data. They are never re-calculated. Mesh changes should not change the
transformation across a coupled interface; to do so would violate the
transformation.
Transformations are now calculated using integral properties of the
patches. This is more numerically stable that the previous methods which
functioned in terms of individual faces. The new routines are also able
to automatically calculate non-zero centres of rotation.
The user input of transformations is backwards compatible, and permits
the user to manually specify varying amounts of the transformation
geometry. Anything left unspecified gets automatically computed from the
patch geometry. Supported specifications are:
1) No specification. Transformations on cyclics are automatically
generated, and cyclicAMI-type patches assume no transformation. For
example (in system/blockMeshDict):
cyclicLeft
{
type cyclic;
neighbourPatch cyclicRight;
faces ((0 1 2 3));
}
cyclicRight
{
type cyclic;
neighbourPatch cyclicLeft;
faces ((4 5 6 7));
}
2) Partial specification. The type of transformation is specified
by the user, as well as the coordinate system if the transform is
rotational. The rotation angle or separation vector is still
automatically generated. This form is useful as the signs of the
angle and separation are opposite on different sides of an interface
and can be difficult to specify correctly. For example:
cyclicLeft
{
type cyclic;
neighbourPatch cyclicRight;
transformType translational;
faces ((0 1 2 3));
}
cyclicRight
{
type cyclic;
neighbourPatch cyclicLeft;
transformType translational;
faces ((4 5 6 7));
}
cyclicAMILeft
{
type cyclicAMI;
neighbourPatch cyclicAMIRight;
transformType rotational;
rotationAxis (0 0 1);
rotationCentre (0.05 -0.01 0);
faces ((8 9 10 11));
}
cyclicAMIRight
{
type cyclicAMI;
neighbourPatch cyclicAMILeft;
transformType rotational;
rotationAxis (0 0 1);
rotationCentre (0.05 -0.01 0);
faces ((12 13 14 15));
}
3) Full specification. All parameters of the transformation are
given. For example:
cyclicLeft
{
type cyclic;
neighbourPatch cyclicRight;
transformType translational;
separaion (-0.01 0 0);
faces ((0 1 2 3));
}
cyclicRight
{
type cyclic;
neighbourPatch cyclicLeft;
transformType translational;
separaion (0.01 0 0);
faces ((4 5 6 7));
}
cyclicAMILeft
{
type cyclicAMI;
neighbourPatch cyclicAMIRight;
transformType rotational;
rotationAxis (0 0 1);
rotationCentre (0.05 -0.01 0);
rotationAngle 60;
faces ((8 9 10 11));
}
cyclicAMIRight
{
type cyclicAMI;
neighbourPatch cyclicAMILeft;
transformType rotational;
rotationAxis (0 0 1);
rotationCentre (0.05 -0.01 0);
rotationAngle 60;
faces ((12 13 14 15));
}
Automatic ordering of faces and points across coupled patches has also
been rewritten, again replacing multiple unsatisfactory implementations.
The new ordering method is more robust on poor meshes as it
geometrically matches only a single face (per contiguous region of the
patch) in order to perform the ordering, and this face is chosen to be
the one with the highest quality. A failure in ordering now only occurs
if the best face in the patch cannot be geometrically matched, whether
as previously the worst face could cause the algorithm to fail.
The oldCyclicPolyPatch has been removed, and the mesh converters which
previously used it now all generate ordered cyclic and baffle patches
directly. This removes the need to run foamUpgradeCyclics after
conversion. In addition the fluent3DMeshToFoam converter now supports
conversion of periodic/shadow pairs to OpenFOAM cyclic patches.
and removed the need for the direct dependency of Ostream on keyType which is
not a primitive IO type and relates specifically to dictionary and not all IO.
Currently these deleted function declarations are still in the private section
of the class declarations but will be moved by hand to the public section over
time as this is too complex to automate reliably.
Replaced all uses of complex Xfer class with C++11 "move" constructors and
assignment operators. Removed the now redundant Xfer class.
This substantial changes improves consistency between OpenFOAM and the C++11 STL
containers and algorithms, reduces memory allocation and copy overhead when
returning containers from functions and simplifies maintenance of the core
libraries significantly.
The writeEntry form is now defined and used consistently throughout OpenFOAM
making it easier to use and extend, particularly to support binary IO of complex
dictionary entries.
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.
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.
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.
