If the sequence of meshes are decomposed independently the number, order and
potentially type of processor patches is likely to change. Thus the processor
patches and patch fields must be replaced with those of the new mesh.
and moveDynamicMesh renamed to moveMesh
Description
Mesh motion and topological mesh change utility.
Executes the mover, topoChanger and distributor specified in the
dynamicMeshDict in a time-loop.
This utility now always creates two patches, and only creates duplicate
faces when they connect to different cells and point in opposite
directions. Now that ACMI has been removed, there is no need to create
duplicate faces on the same cell and with similar orientations. This is
unituitive and is now considered an invalid mesh topology.
The preferred syntax for createBaffles is now as follows:
internalFacesOnly true;
baffles
{
cyclics
{
type faceZone;
zoneName cyclicFaces;
owner
{
name cyclicLeft;
type cyclic;
neighbourPatch cyclicRight;
}
neighbour
{
name cyclicRight;
type cyclic;
neighbourPatch cyclicLeft;
}
}
}
Note that the 'patches' sub-dictionary is not needed any more; the
'owner' and 'neighbour' sub-dictionaries can be in the same dictionary
as the parameters with which faces are selected. For backwards
compatibility, however, a 'patches' sub-dictionary is still permitted,
as are keywords 'master' and 'slave' (in place of 'owner' and
'neighbour', respectively).
The 'patchPairs' syntax has been removed. Whilst consise, this syntax
made a number of assumptions and decisions regarding naming conventions
that were not sufficiently intuitive for the user to understand without
extensive reference to the code. If identical boundaries are desired on
both sides of the patch, dictionary substitution provides a more
intuitive way of minimising the amount of specifiection required. For
example, to create two back-to-back walls, the following specification
could be used:
internalFacesOnly true;
fields true;
baffles
{
walls
{
type faceZone;
zoneName wallFaces;
owner
{
name baffleWallLeft;
type wall;
patchFields
{
p
{
type zeroGradient;
}
U
{
type noSlip;
}
}
}
neighbour
{
name baffleWallRight;
$owner; // <-- Use the same settings as for the owner
}
}
}
The 'pointSync' setting in createPatchDict is now optional and defaults
to false. This setting is very rarely used. A number of unused
'createPatchDict' files have also been removed and obsolete information
has been removed from the annotated example dictionaries.
When cloning a case, users can copy the field data from the
from the latest time directory in the source case, using
the -latestTime option.
The -startFrom option enables the copied time directory to be
renamed, often as the '0' (zero) directory in the new case, e.g.
foamCloneCase -latestTime -startFrom 0 sourceCase newCase
When the time directories in the source and new cases are
different, the uniform directory and flux field "phi" are
deleted from the copied time directory to avoid incorrect
initial state.
The functionality provided by 'cyclicACMI' and 'cyclicRepeatAMI' has
been entirely superseded by non-conformal coupled (NCC). All references
to 'cyclicACMI' and 'cyclicRepeatAMI' have therefore been removed.
See previous commits 569fa31d and 420866cf for more explanation,
instructions on updating, and relevant tutorial cases.
This major development provides coupling of patches which are
non-conformal, i.e. where the faces of one patch do not match the faces
of the other. The coupling is fully conservative and second order
accurate in space, unlike the Arbitrary Mesh Interface (AMI) and
associated ACMI and Repeat AMI methods which NCC replaces.
Description:
A non-conformal couple is a connection between a pair of boundary
patches formed by projecting one patch onto the other in a way that
fills the space between them. The intersection between the projected
surface and patch forms new faces that are incorporated into the finite
volume mesh. These new faces are created identically on both sides of
the couple, and therefore become equivalent to internal faces within the
mesh. The affected cells remain closed, meaning that the area vectors
sum to zero for all the faces of each cell. Consequently, the main
benefits of the finite volume method, i.e. conservation and accuracy,
are not undermined by the coupling.
A couple connects parts of mesh that are otherwise disconnected and can
be used in the following ways:
+ to simulate rotating geometries, e.g. a propeller or stirrer, in which
a part of the mesh rotates with the geometry and connects to a
surrounding mesh which is not moving;
+ to connect meshes that are generated separately, which do not conform
at their boundaries;
+ to connect patches which only partially overlap, in which the
non-overlapped section forms another boundary, e.g. a wall;
+ to simulate a case with a geometry which is periodically repeating by
creating multiple couples with different transformations between
patches.
The capability for simulating partial overlaps replaces the ACMI
functionality, currently provided by the 'cyclicACMI' patch type, and
which is unreliable unless the couple is perfectly flat. The capability
for simulating periodically repeating geometry replaces the Repeat AMI
functionality currently provided by the 'cyclicRepeatAMI' patch type.
Usage:
The process of meshing for NCC is very similar to existing processes for
meshing for AMI. Typically, a mesh is generated with an identifiable set
of internal faces which coincide with the surface through which the mesh
will be coupled. These faces are then duplicated by running the
'createBaffles' utility to create two boundary patches. The points are
then split using 'splitBaffles' in order to permit independent motion of
the patches.
In AMI, these patches are assigned the 'cyclicAMI' patch type, which
couples them using AMI interpolation methods.
With NCC, the patches remain non-coupled, e.g. a 'wall' type. Coupling
is instead achieved by running the new 'createNonConformalCouples'
utility, which creates additional coupled patches of type
'nonConformalCyclic'. These appear in the 'constant/polyMesh/boundary'
file with zero faces; they are populated with faces in the finite volume
mesh during the connection process in NCC.
For a single couple, such as that which separates the rotating and
stationary sections of a mesh, the utility can be called using the
non-coupled patch names as arguments, e.g.
createNonConformalCouples -overwrite rotatingZoneInner rotatingZoneOuter
where 'rotatingZoneInner' and 'rotatingZoneOuter' are the names of the
patches.
For multiple couples, and/or couples with transformations,
'createNonConformalCouples' should be run without arguments. Settings
will then be read from a configuration file named
'system/createNonConformalCouplesDict'. See
'$FOAM_ETC/caseDicts/annotated/createNonConformalCouplesDict' for
examples.
Boundary conditions must be specified for the non-coupled patches. For a
couple where the patches fully overlap, boundary conditions
corresponding to a slip wall are typically applied to fields, i.e
'movingWallSlipVelocity' (or 'slip' if the mesh is stationary) for
velocity U, 'zeroGradient' or 'fixedFluxPressure' for pressure p, and
'zeroGradient' for other fields. For a couple with
partially-overlapping patches, boundary conditions are applied which
physically represent the non-overlapped region, e.g. a no-slip wall.
Boundary conditions also need to be specified for the
'nonConformalCyclic' patches created by 'createNonConformalCouples'. It
is generally recommended that this is done by including the
'$FOAM_ETC/caseDicts/setConstraintTypes' file in the 'boundaryField'
section of each of the field files, e.g.
boundaryField
{
#includeEtc "caseDicts/setConstraintTypes"
inlet
{
...
}
...
}
For moving mesh cases, it may be necessary to correct the mesh fluxes
that are changed as a result of the connection procedure. If the
connected patches do not conform perfectly to the mesh motion, then
failure to correct the fluxes can result in noise in the pressure
solution.
Correction for the mesh fluxes is enabled by the 'correctMeshPhi' switch
in the 'PIMPLE' (or equivalent) section of 'system/fvSolution'. When it
is enabled, solver settings are required for 'MeshPhi'. The solution
just needs to distribute the error enough to dissipate the noise. A
smooth solver with a loose tolerance is typically sufficient, e.g. the
settings in 'system/fvSolution' shown below:
solvers
{
MeshPhi
{
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-2;
relTol 0;
}
...
}
PIMPLE
{
correctMeshPhi yes;
...
}
The solution of 'MeshPhi' is an inexpensive computation since it is
applied only to a small subset of the mesh adjacent to the
couple. Conservation is maintained whether or not the mesh flux
correction is enabled, and regardless of the solution tolerance for
'MeshPhi'.
Advantages of NCC:
+ NCC maintains conservation which is required for many numerical
schemes and algorithms to operate effectively, in particular those
designed to maintain boundedness of a solution.
+ Closed-volume systems no longer suffer from accumulation or loss of
mass, poor convergence of the pressure equation, and/or concentration
of error in the reference cell.
+ Partially overlapped simulations are now possible on surfaces that are
not perfectly flat. The projection fills space so no overlaps or
spaces are generated inside contiguously overlapping sections, even if
those sections have sharp angles.
+ The finite volume faces created by NCC have geometrically accurate
centres. This makes the method second order accurate in space.
+ The polyhedral mesh no longer requires duplicate boundary faces to be
generated in order to run a partially overlapped simulation.
+ Lagrangian elements can now transfer across non-conformal couplings in
parallel.
+ Once the intersection has been computed and applied to the finite
volume mesh, it can use standard cyclic or processor cyclic finite
volume boundary conditions, with no need for additional patch types or
matrix interfaces.
+ Parallel communication is done using the standard
processor-patch-field system. This is more efficient than alternative
systems since it has been carefully optimised for use within the
linear solvers.
+ Coupled patches are disconnected prior to mesh motion and topology
change and reconnected afterwards. This simplifies the boundary
condition specification for mesh motion fields.
Resolved Bug Reports:
+ https://bugs.openfoam.org/view.php?id=663
+ https://bugs.openfoam.org/view.php?id=883
+ https://bugs.openfoam.org/view.php?id=887
+ https://bugs.openfoam.org/view.php?id=1337
+ https://bugs.openfoam.org/view.php?id=1388
+ https://bugs.openfoam.org/view.php?id=1422
+ https://bugs.openfoam.org/view.php?id=1829
+ https://bugs.openfoam.org/view.php?id=1841
+ https://bugs.openfoam.org/view.php?id=2274
+ https://bugs.openfoam.org/view.php?id=2561
+ https://bugs.openfoam.org/view.php?id=3817
Deprecation:
NCC replaces the functionality provided by AMI, ACMI and Repeat AMI.
ACMI and Repeat AMI are insufficiently reliable to warrant further
maintenance so are removed in an accompanying commit to OpenFOAM-dev.
AMI is more widely used so will be retained alongside NCC for the next
version release of OpenFOAM and then subsequently removed from
OpenFOAM-dev.
This change means this function is determining the sequence in which
points are plotted topologically. This makes it possible to plot a layer
average along a pipe that goes through many changes of direction.
Previously, the function determined the order by means of a geometric
sort in the plot direction. This only worked when the layers were
perpendicular to one of the coordinate axes.
This is a simple function that provides a convenient way for a user to
call fvc::reconstruct for the purposes of post-processing flux fields;
e.g., to construct a cell velocity from a face flux.
It can be used to generate output during a run by adding the following
settings to a case's controlDict:
functions
{
#includeFunc reconstruct(phi)
}
Or it can be executed as a postProcessing step by calling:
postProcess -func "reconstruct(phi)"
This new mapping structure is designed to support run-time mesh-to-mesh mapping
to allow arbitrary changes to the mesh structure, for example during extreme
motion requiring significant topology change including region disconnection etc.
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.
This is a map data structure rather than a class or function which performs the
mapping operation so polyMeshDistributionMap is more logical and comprehensible
than mapDistributePolyMesh.
It is not clear for what cases the minVol control is useful or necessary and for
some cases it causes problems with snapping and layer addition if not set to a
sufficiently small value.
motionSmootherAlgoCheck::checkMesh is used by snappyHexMesh to check the mesh
after snapping and morphing. The minVol test which checks for collapsed cells
is now relative to the cube of the minimum bounding box length so that it is
less dependent on the size of the geometry and less likely to need changing for
very small geometries.
The default value is set in
etc/caseDicts/mesh/generation/meshQualityDict
etc/caseDicts/mesh/generation/meshQualityDict.cfg
//- Minimum cell pyramid volume relative to min bounding box length^3
// Set to a fraction of the smallest cell volume expected.
// Set to very negative number (e.g. -1e30) to disable.
minVol 1e-10;
The unused minArea and minTriangleTwist tests have been removed
Solver for steady or transient buoyant, turbulent flow of compressible fluids
for ventilation and heat-transfer, with optional mesh motion and mesh topology
changes. Created by merging buoyantSimpleFoam and buoyantPimpleFoam to provide
a more general solver and simplify maintenance.
With the changes to chemistryModel to evaluate and integrate reaction rates
mass-fraction based rather than mole-fraction based ISAT is now independent of
the thermodynamics and with some restructuring of chemistryModel and the
addition of the non-templated base-class odeChemistryModel is has been possible
to un-template chemistryTabulationMethods and ISAT in particular. This
simplifies the ISAT code and hence maintenance as well as reducing the
compilation time of chemistryModel on the various thermo packages.
Following the addition of the new moments functionObject, all related
functionality was removed from sizeDistribution.
In its revised version, sizeDistribution allows for different kinds of
weighted region averaging in case of field-dependent representative
particle properties.
A packaged function has also been added to allow for command line solver
post-processing.
For example, the following function object specification returns the
volume-based number density function:
numberDensity
{
type sizeDistribution;
libs ("libmultiphaseEulerFoamFunctionObjects.so");
writeControl writeTime;
populationBalance bubbles;
functionType numberDensity;
coordinateType volume;
setFormat raw;
}
The same can be achieved using a packaged function:
#includeFunc sizeDistribution
(
populationBalance=bubbles,
functionType=numberDensity,
coordinateType=volume,
funcName=numberDensity
)
Or on the command line:
multiphaseEulerFoam -postProcess -func "
sizeDistribution
(
populationBalance=bubbles,
functionType=numberDensity,
coordinateType=volume,
funcName=numberDensity
)"
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
This function calculates integral (integer moments) or mean properties
(mean, variance, standard deviation) of a size distribution computed with
multiphaseEulerFoam. It has to be run with multiphaseEulerFoam, either
at run-time or with -postProcess. It will not work with the postProcess
utility.
The following function object specification for example returns the first
moment of the volume-based number density function which is equivalent to
the phase fraction of the particulate phase:
moments
{
type moments;
libs ("libmultiphaseEulerFoamFunctionObjects.so");
executeControl timeStep;
writeControl writeTime;
populationBalance bubbles;
momentType integerMoment;
coordinateType volume;
order 1;
}
The same can be achieved using a packaged function:
#includeFunc moments
(
populationBalance=bubbles,
momentType=integerMoment,
coordinateType=volume,
order=1,
funcName=moments
)
Or on the command line:
multiphaseEulerFoam -postProcess -func "
moments
(
populationBalance=bubbles,
momentType=integerMoment,
coordinateType=volume,
order=1,
funcName=moments
)"
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
also adding optional "libs" entry to renumberMeshDict so that the
libzoltanRenumber.so can be loaded at run-time rather than having to recompile
and relink the renumberMesh utility to support it.
When snappyHexMesh is run in parallel it re-balances the mesh during refinement
and layer addition by redistribution which requires a decomposition method
that operates in parallel, e.g. hierachical or ptscotch. decomposePar uses a
decomposition method which operates in serial e.g. hierachical but NOT
ptscotch. In order to run decomposePar followed by snappyHexMesh in parallel it
has been necessary to change the method specified in decomposeParDict but now
this is avoided by separately specifying the decomposition and distribution
methods, e.g. in the incompressible/simpleFoam/motorBike case:
numberOfSubdomains 6;
decomposer hierarchical;
distributor ptscotch;
hierarchicalCoeffs
{
n (3 2 1);
order xyz;
}
The distributor entry is also used for run-time mesh redistribution, e.g. in the
multiphase/interFoam/RAS/floatingObject case re-distribution for load-balancing
is enabled in constant/dynamicMeshDict:
distributor
{
type distributor;
libs ("libfvMeshDistributors.so");
redistributionInterval 10;
}
which uses the distributor specified in system/decomposeParDict:
distributor hierarchical;
This rationalisation provides the structure for development of mesh
redistribution and load-balancing.
This function generates plots of fields averaged over the layers in the
mesh. It is a generalised replacement for the postChannel utility, which
has been removed. An example of this function's usage is as follows:
layerAverage1
{
type layerAverage;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
setFormat raw;
// Patches and/or zones from which layers extrude
patches (bottom);
zones (quarterPlane threeQuartersPlane);
// Spatial component against which to plot
component y;
// Is the geometry symmetric around the centre layer?
symmetric true;
// Fields to average and plot
fields (pMean pPrime2Mean UMean UPrime2Mean k);
}
The code relating to extending refinement to the span of the facet/triangles
intersected by the refinement distance referred to in report
https://bugs.openfoam.org/view.php?id=3361
and temporarily removed may now be selected by the optional
castellatedMeshControls:extendedRefinementSpan entry in snappyHexMeshDict. It
in not clear if this control is generally beneficial and very few users have
reported a preference and too few example cases have been provided to make a
balanced judgement so it has been decided to reinstate the previous default
behaviour and default extendedRefinementSpan to true.
Sampled sets and streamlines now write all their fields to the same
file. This prevents excessive duplication of the geometry and makes
post-processing tasks more convenient.
"axis" entries are now optional in sampled sets and streamlines. When
omitted, a default entry will be used, which is chosen appropriately for
the coordinate set and the write format. Some combinations are not
supported. For example, a scalar ("x", "y", "z" or "distance") axis
cannot be used to write in the vtk format, as vtk requires 3D locations
with which to associate data. Similarly, a point ("xyz") axis cannot be
used with the gnuplot format, as gnuplot needs a single scalar to
associate with the x-axis.
Streamlines can now write out fields of any type, not just scalars and
vectors, and there is no longer a strict requirement for velocity to be
one of the fields.
Streamlines now output to postProcessing/<functionName>/time/<file> in
the same way as other functions. The additional "sets" subdirectory has
been removed.
The raw set writer now aligns columns correctly.
The handling of segments in coordSet and sampledSet has been
fixed/completed. Segments mean that a coordinate set can represent a
number of contiguous lines, disconnected points, or some combination
thereof. This works in parallel; segments remain contiguous across
processor boundaries. Set writers now only need one write method, as the
previous "writeTracks" functionality is now handled by streamlines
providing the writer with the appropriate segment structure.
Coordinate sets and set writers now have a convenient programmatic
interface. To write a graph of A and B against some coordinate X, in
gnuplot format, we can call the following:
setWriter::New("gnuplot")->write
(
directoryName,
graphName,
coordSet(true, "X", X), // <-- "true" indicates a contiguous
"A", // line, "false" would mean
A, // disconnected points
"B",
B
);
This write function is variadic. It supports any number of
field-name-field pairs, and they can be of any primitive type.
Support for Jplot and Xmgrace formats has been removed. Raw, CSV,
Gnuplot, VTK and Ensight formats are all still available.
The old "graph" functionality has been removed from the code, with the
exception of the randomProcesses library and associated applications
(noise, DNSFoam and boxTurb). The intention is that these should also
eventually be converted to use the setWriters. For now, so that it is
clear that the "graph" functionality is not to be used elsewhere, it has
been moved into a subdirectory of the randomProcesses library.
Description
Transport package using the Andrade function for the natural logarithm of
dynamic viscosity and thermal conductivity of liquids:
\verbatim
log(mu) = muCoeffs[0] + muCoeffs[1]*T + muCoeffs[2]*sqr(T)
+ muCoeffs_[3]/(muCoeffs_[4] + T)
log(kappa) = kappaCoeffs[0] + kappaCoeffs[1]*T + kappaCoeffs[2]*sqr(T)
+ kappaCoeffs_[3]/(kappaCoeffs_[4] + T)
);
\endverbatim
References:
\verbatim
Andrade, E. D. C. (1934).
XLI. A theory of the viscosity of liquids.—Part I.
The London, Edinburgh, and Dublin Philosophical Magazine
and Journal of Science, 17(112), 497-511.
Andrade, E. D. C. (1934).
LVIII. A theory of the viscosity of liquids.—Part II.
The London, Edinburgh, and Dublin Philosophical Magazine
and Journal of Science, 17(113), 698-732.
\endverbatim
Usage
\table
Property | Description
muCoeffs | Dynamic viscosity polynomial coefficients
kappaCoeffs | Thermal conductivity polynomial coefficients
\endtable
Example of the specification of the transport properties for water@200bar:
\verbatim
transport
{
muCoeffs (-25.8542 0.031256 -2.2e-05 3289.918 -11.4784);
kappaCoeffs (-2.56543 0.008794 -9.8e-06 100.368 0);
}
\endverbatim
With the general run-time selectable fvMeshMovers engine compression simulations
can be performed with reactingFoam so there is no longer any need for engine
specific solvers or engineMesh.
An engineFoam script is provided to redirect users to reactingFoam with
instructions.
Description
Evolves a passive scalar transport equation.
- To specify the field name set the \c field entry
- To employ the same numerical schemes as another field set
the \c schemesField entry,
- The \c diffusivity entry can be set to \c none, \c constant, \c viscosity
- A constant diffusivity is specified with the \c D entry,
- If a momentum transport model is available and the \c viscosity
diffusivety option specified an effective diffusivity may be constructed
from the laminar and turbulent viscosities using the diffusivity
coefficients \c alphal and \c alphat:
\verbatim
D = alphal*nu + alphat*nut
\endverbatim
Example:
\verbatim
#includeFunc scalarTransport(T, alphaD=1, alphaDt=1)
\endverbatim
For incompressible flow the passive scalar may optionally be solved with the
MULES limiter and sub-cycling or semi-implicit in order to maintain
boundedness, particularly if a compressive, PLIC or MPLIC convection
scheme is used.
Example:
\verbatim
#includeFunc scalarTransport(tracer, diffusion=none)
with scheme specification:
div(phi,tracer) Gauss interfaceCompression vanLeer 1;
and solver specification:
tracer
{
nCorr 1;
nSubCycles 3;
MULESCorr no;
nLimiterIter 5;
applyPrevCorr yes;
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-8;
relTol 0;
diffusion
{
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-8;
relTol 0;
}
}
\endverbatim
