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.
This switch controls whether or not the model clips a droplet's outlet
mass flow rate to zero or permits it to become negative and thereby
represent condensation. By default condensation is not permitted.
There is no longer any need for the surfaceFilmModel abstract base class and
"New" selection method as surface films are now handled within the fvModel
framework. This makes the surfaceFilmModel entry in the surfaceFilmProperties
dictionary redundant.
The surfaceFilm and VoFSurfaceFilm fvModels now instantiate a thermoSingleLayer
providing direct access to all the film functions, simplifying the
implementation better ensuring consistency between the film and primary region
equations.
The chemistry model now solves a system of mass fractions, temperature
and pressure, rather than a system of concentrations, temperature and
pressure.
The new form now accounts for the change in reaction rate associated
with thermal expansion. Thermal expansion (or contraction) can dilute
(or concentrate) the species concentrations, thereby reducing (or
increasing) the reaction rates. Previously it was not possible to
include this term because it was not computationally feasible to
evaluate it in a system in which the state variable was concentration.
The reaction rate interface has been simplified with respect to the
generation of derivatives. Reactions are defined as k*C, where k is the
reaction rate and C is the product of concentrations (raised to their
stoichiomentric coefficients and/or specified powers). Reaction rate
classes now provide two logical functions governing the derivatives of
k; i.e., ddT (derivative w.r.t. temperature) and ddc (derivative w.r.t.
concentration). Previously the reaction rate interface was closely
related to the form of third-body reactions, which made it inconvenient
to implement rates that were not very third-body-like.
It is now possible to verify the implementations of the jacobian methods
by comparison with finite-difference based evaluations of the rate
methods. This has been done and a number of bugs have been found and
fixed in the reaction rate classes.
This is needed by chemistry to represent the effect of thermal expansion
as a result of reaction heat on the concentrations used to evalate the
reaction rates.
Fixed field size missmatch bug in binary tree rebalancing. Fixed issue
where CPU time was not accumulated for retrieve. Corrected retrieve so
that it extrapolates the entire output vector, including temperature and
pressure.
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.
These models are quite configuration specific. It makes sense to make
them sub-models of the force (drag or lift) models that use them, rather
than making them fundamental properties of the phase system.
The set is now specified with a "set" keyword, as the fact that it is a
faceSet is clear from context. The old "faceSet" keyword is maintained
for backwards compatibility.
Basic support is now provided for dynamic mesh redistribution, particularly for
load-balancing. The mesh distributor is selected in the optional 'distributor'
entry in dynamicMeshDict, for example in the
multiphase/interFoam/RAS/floatingObject tutorial case when run in parallel using
the new Allrun-parallel script
distributor
{
type decomposer;
libs ("libfvMeshDistributors.so");
redistributionInterval 10;
}
in which the 'decomposer' form of redistribution is selected to call the mesh
decomposition method specified in decomposeParDict to re-decompose the mesh for
redistribution. The redistributionInterval entry specifies how frequently mesh
redistribution takes place, in the above every 10th time-step. An optional
maxImbalance entry is also provided to control redistribution based on the cell
distribution imbalance:
Class
Foam::fvMeshDistributor::decomposer
Description
Dynamic mesh redistribution using the decomposer
Usage
Example of single field based refinement in all cells:
\verbatim
distributor
{
type decomposer;
libs ("libfvMeshDistributors.so");
// How often to redistribute
redistributionInterval 10;
// Maximum fractional cell distribution imbalance
// before rebalancing
maxImbalance 0.1;
}
\endverbatim
Currently mesh refinement/unrefinement and motion with redistribution is
supported but many aspects of OpenFOAM are not yet and will require further
development, in particular fvModels and Lagrangian.
Also only the geometry-based simple and hierarchical decomposition method are
well behaved for redistribution, scotch and ptScotch cause dramatic changes in
mesh distribution with a corresponding heavy communications overhead limiting
their usefulness or at least the frequency with which they should be called to
redistribute the mesh.
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);
}
Pressure reduction is now applied only for entrained flow, fixed pressure is
applied to outflow to improve stability for complex recirculating flow exiting
the domain. This is the same approach used in the totalPressure boundary
condition.
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.
To support mesh redistribution for load-balancing etc. all MeshObjects requiring
a special updateMesh(const mapPolyMesh&) function will also require a
distribute(const mapDistributePolyMesh&) to handle the redistribution of
no-field and unregistered mesh-related state data.
Fortunately there are not many MeshObjects requiring a special distribute(const
mapDistributePolyMesh&) implementation but it will take some time to implement
and test all those that do; this patch provides those for displacement-based
mesh-movers.
wallHeatFlux can now be used to calculate the phase wall heat-flux in
multiphase systems, e.g.
multiphaseEulerFoam -postProcess -func 'wallHeatFlux(phase=water)' -latestTime
wallShearStress can now be used to calculate the phase wall shear-stress in
multiphase systems, e.g.
multiphaseEulerFoam -postProcess -func 'wallShearStress(phase=water)' -latestTime
Description
This boundary condition provides an entrainment condition for pressure
including support for supersonic jets exiting the domain.
Usage
\table
Property | Description | Required | Default value
rho | Density field name | no | rho
psi | Compressibility field name | no | thermo:psi
gamma | Heat capacity ratio (cp/Cv) | yes |
phi | Flux field name | no | phi
p0 | Reference pressure | yes |
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type transonicEntrainmentPressure;
gamma 1.4;
p0 uniform 1e5;
}
\endverbatim
See also
Foam::entrainmentPressureFvPatchScalarField
Foam::mixedFvPatchField
For some systems the thermal coupling between the solid and fluid regions
dominates overall convergence and it may be beneficial to sub-iterate over the
thermal system as the energy solution is cheaper than the pressure-velocity
system. To test this the new optional nEcorr entry in system/fvSolution is
provided which defaults to 1, e.g.
PIMPLE
{
nOuterCorrectors 1;
nEcorr 2;
}
If this proves useful it could be extended and improved by adding convergence
controls.
Note that the solution of the solid regions is now before the fluid regions as
it make more sense if solid regions are sources or sinks of heat to solve them
before the fluid.
