The MomentumTransportModels library now builds of a standard set of
phase-incompressible and phase-compressible models. This replaces most
solver-specific builds of these models.
This has been made possible by the addition of a new
"dynamicTransportModel" interface, from which all transport classes used
by the momentum transport models now derive. For the purpose of
disambiguation, the old "transportModel" has also been renamed
"kinematicTransportModel".
This change has been made in order to create a consistent definition of
phase-incompressible and phase-compressible MomentumTransportModels,
which can then be looked up by functionObjects, fvModels, and similar.
Some solvers still build specific momentum transport models, but these
are now in addition to the standard set. The solver does not build all
the models it uses.
There are also corresponding centralised builds of phase dependent
ThermophysicalTransportModels.
Description
Transform (translate, rotate, scale) a surface.
Usage
\b surfaceTransformPoints "\<transformations\>" \<input\> \<output\>
Supported transformations:
- \par translate=<translation vector>
Translational transformation by given vector
- \par rotate=(\<n1 vector\> \<n2 vector\>)
Rotational transformation from unit vector n1 to n2
- \par Rx=\<angle [deg] about x-axis\>
Rotational transformation by given angle about x-axis
- \par Ry=\<angle [deg] about y-axis\>
Rotational transformation by given angle about y-axis
- \par Rz=\<angle [deg] about z-axis\>
Rotational transformation by given angle about z-axis
- \par Ra=\<axis vector\> \<angle [deg] about axis\>
Rotational transformation by given angle about given axis
- \par scale=\<x-y-z scaling vector\>
Anisotropic scaling by the given vector in the x, y, z
coordinate directions
Example usage:
surfaceTransformPoints \
"translate=(-0.586 0 -0.156), \
Ry=3.485, \
translate=(0.586 0 0.156)" \
constant/geometry/w3_orig.stl constant/geometry/w3.stl
The transformation sequence is specified like a substitution string used by
Description
Transform (translate, rotate, scale) a surface.
The rollPitchYaw option takes three angles (degrees):
- roll (rotation about x) followed by
- pitch (rotation about y) followed by
- yaw (rotation about z)
The yawPitchRoll does yaw followed by pitch followed by roll.
Usage
\b surfaceTransformPoints "\<transformations\>" \<input\> \<output\>
Example usage:
surfaceTransformPoints \
"translate=(-0.586 0 -0.156), \
rollPitchYaw=(0 -3.485 0), \
translate=(0.586 0 0.156)" \
constant/geometry/w3_orig.stl constant/geometry/w3.stl
Multiple substitutions can be made using the convenient -set "<substitutions>"
option which combines the selection of the entries with the substitutions made
on them using the same argument syntax used by #includeFunc, e.g.
foamDictionary system/controlDict -set "startTime=2000, endTime=3000"
The new fvModels is a general interface to optional physical models in the
finite volume framework, providing sources to the governing conservation
equations, thus ensuring consistency and conservation. This structure is used
not only for simple sources and forces but also provides a general run-time
selection interface for more complex models such as radiation and film, in the
future this will be extended to Lagrangian, reaction, combustion etc. For such
complex models the 'correct()' function is provided to update the state of these
models at the beginning of the PIMPLE loop.
fvModels are specified in the optional constant/fvModels dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The new fvConstraints is a general interface to optional numerical constraints
applied to the matrices of the governing equations after construction and/or to
the resulting field after solution. This system allows arbitrary changes to
either the matrix or solution to ensure numerical or other constraints and hence
violates consistency with the governing equations and conservation but it often
useful to ensure numerical stability, particularly during the initial start-up
period of a run. Complex manipulations can be achieved with fvConstraints, for
example 'meanVelocityForce' used to maintain a specified mean velocity in a
cyclic channel by manipulating the momentum matrix and the velocity solution.
fvConstraints are specified in the optional system/fvConstraints dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The separation of fvOptions into fvModels and fvConstraints provides a rational
and consistent separation between physical and numerical models which is easier
to understand and reason about, avoids the confusing issue of location of the
controlling dictionary file, improves maintainability and easier to extend to
handle current and future requirements for optional complex physical models and
numerical constraints.
Specifying a plane with which to subset feature edges is now done using
the same dictionary syntax used elsewhere in OpenFOAM. For example, in
system/surfaceFeaturesDict:
subsetFeatures
{
// Include only edges that intersect the plane
plane
{
planeType pointAndNormal;
point (0 0 0);
normal (1 0 0);
}
...
}
Originally the only supported geometry specification were triangulated surfaces,
hence the name of the directory: constant/triSurface, however now that other
surface specifications are supported and provided it is much more logical that
the directory is named accordingly: constant/geometry. All tutorial and
template cases have been updated.
Note that backward compatibility is provided such that if the constant/geometry
directory does not exist but constant/triSurface does then the geometry files
are read from there.
Geometric point merging has an inherent chance of failure that occurs
when a mesh contains valid distinct points that are closer together than
the supplied tolerance. It is beneficial to avoid such merging whenever
possible.
reconstructParMesh does not need explicit point merging any more. Points
may be duplicated temporarily when processor meshes are combined which
share points and edges but not faces. Ultimately, however,
reconstructParMesh reconstructs the entire mesh so everything eventually
gets face-connected and all point duplications get resolved.
fvMeshDistribute requires point-merging, as the entire mesh is not
constructed. However, since 5d4c8f5d, this process has been purely
topological and has not relied on any of the geometric merging processes
triggered by utilised code.
As such, all geometric point merging operations and tolerances have been
removed from these two implementations, as well as in lower level code
in faceCoupleInfo and polyMeshAdder. faceCoupleInfo has also had support
for face and edge splits removed as this was not being used. This change
will have improved the robustness of both reconstruction and
redistributuon and has greatly reduced the total amount of code
involved.
The only geometric tolerance-based matching still being performed by
either of these processes is as a result of coupled patch ordering in
fvMeshDistribute. It is possible that this is not necessary either
(though at present coupled patch ordering is certainly needed
elsewhere). This warrants further investigation.
cpp is no longer used to pre-process Make/files files allowing standard make '#'
syntax for comments, 'ifdef', 'ifndef' conditionals etc. This is make possible
by automatically pre-pending SOURCE += to each of the source file names in
Make/files.
The list of source files compile can be specified either as a simple list of
files in Make/files e.g.
# Note: fileMonitor assumes inotify by default. Compile with -DFOAM_USE_STAT
# to use stat (=timestamps) instead of inotify
fileMonitor.C
ifdef SunOS64
dummyPrintStack.C
else
printStack.C
endif
LIB = $(FOAM_LIBBIN)/libOSspecific
or
or directly as the SOURCE entry which is used in the Makefile:
SOURCE = \
adjointOutletPressure/adjointOutletPressureFvPatchScalarField.C \
adjointOutletVelocity/adjointOutletVelocityFvPatchVectorField.C \
adjointShapeOptimizationFoam.C
EXE = $(FOAM_APPBIN)/adjointShapeOptimizationFoam
In either form make syntax for comments and conditionals is supported.
so that it can be included directly into the wmake Makefile to allow full
support of gmake syntax, variables, functions etc.
The Make/files file handled in the same manner as the Make/options file if it
contains the SOURCE entry otherwise it is first processed by cpp for backward
compatibility.
TableBase, TableFile and Table now combined into a single simpler Table class
which handle both the reading of embedded and file data using the generalised
TableReader. The new EmbeddedTableReader handles the embedded data reading
providing the functionality of the original Table class within the same
structure that can read the data from separate files.
The input format defaults to 'embedded' unless the 'file' entry is present and
the Table class is added to the run-time selection table under the name 'table'
and 'tableFile' which provides complete backward comparability. However it is
advisable to migrate cases to use the new 'table' entry and all tutorial cases
have been updated.
The current rough wall functions cover most requirements and there is no clear
need to maintain nutUTabulatedWallFunctionFvPatchScalarField and associated
clutter.
This improves paraview's handling of VTK files which only contain
points. It means the points are visible without glyph-ing, and provides
the necessary input for some filters to operate correctly.
so that foamDictionary conveniently supports the same format as the #includeFunc
argument list, e.g.
foamDictionary -set 'fieldAverage(U, p, prime2Mean = yes)' fieldAverage
The unnamed field arguments 'U' and 'p' are ignored by foamDictionary.
The vtk libraries are not fully independent of the paraview
installation, so in order to have multiple valid compilations of the
PVReaders (which is useful for testing) we need multiple versions of
these libraries, too. So, these libraries have been put into
$PV_PLUGIN_PATH, which is a paraview-version-specific subdirectory of
$FOAM_LIBBIN.
gcc version 5 and above and clang version 3.4 and above fully support the C++14
standard and the compilation rules of OpenFOAM-dev now require this support
allowing for further development and maintenance to benefit from the additional
language features provided in C++14.
foamDictionary operates on individual dictionary files irrespective of their
location or case they may be associated with and hence a case database is not
needed to read them.
using the new nonUniformTable to interpolate between the values vs temperature
provided. All properties (density, heat capacity, viscosity and thermal
conductivite) are considered functions of temperature only and the equation of
state is thus incompressible. Built-in mixing rules corresponding to those in
the other thermo and transport models are not efficient or practical for
tabulated data and so these models are currently only instantiated for the pure
specie/mixture rhoThermo package but a general external mixing method will be
added in the future.
To handle reactions the Jacobian function dKcdTbyKc has been rewritten to use
the Gstd and S functions directly removing the need for the miss-named dGdT
function and hence removing the bugs in the implementation of that function for
some of the thermo models. Additionally the Hc() function has been renamed
Hf() (heat of formation) which is more commonly used terminology and consistent
with the internals of the thermo models.
