The distributions have been extended in various ways to permit usage in
a greater variety of situations...
The distributions now have write methods which allow a distribution to
be written into a field file for restart, therby permitting their usage
in boundary conditions and similar. Their read methods now also support
dimension-checked unit conversions for all their parameters.
An additional selector has been added that allows a distribution to be
re-constructed with a different sample size exponent.
The distributions now own their random generator, thereby simplifying
their usage and preventing the need for a (potentially dangling)
reference member. This makes sense now as the random generators do not
rely on global state; individual sub-models can and should own their own
random generator and manage its initialisation and restart. This
principle should be extended to other parts of the code in future.
A random generator can now be constructed with a global flag. If the
flag is false then the provided seed will be randomised across the
different processes. If the flag is true then the synchronicity of the
generators state will be checked when performing certain operations in
debug mode.
The coefficients in the polynomial are now specified in order of
increasing exponent, starting from the constant coefficient (i.e., zero
exponent). Exponents are no longer specified. This better fits the
definition of a polynomial, and it prevents the strange scenario when if
exponents are given as a vector or tensor or similar then the units of
the coefficients are not the same across the different components.
For example, polynomial y = -1 + x^2 + 2x^3 can be specified as:
<name> polynomial (-1 0 1 2);
Or, alternatively:
<name>
{
type polynomial;
coeffs (-1 0 1 2);
}
The concept of cell and face inflation proved unworkable in general and has been
replaced by the more flexible and robust cell-splitting combined with
conservative interpolative mapping and mesh morphing as appropriate.
This provides finer control as to when the changes get constructed and
initial stitching is performed. These is needed by certain processes,
notably decomposition and reconstruction.
By default, the mesh still performs all these operations on a "normal"
read-construction. A flag has to be passed explicitly to the constructor
in order to prevent the post-construction steps.
All property functions in the low-level templated thermo property
implementations and the high-level virtual interfaces have been made
consistent. All energies and enthalpies are lower case to denote that
they are specific quantities. Molar functions have been removed as these
are no longer used anywhere.
The dictionary/table-based expansions provided by stringOps::expand are
now too situation specific for this utility to concisely test with a
single complex string. These expansions are fundamental to the operation
of dictionary and dynamic code and receive good testing coverage in the
tutorial test loop anyway.
Specific names have been given for expand functions. Unused functions
have been removed, and functions only used locally have been removed
from the namespace. Documentation has been corrected. Default and
alternative value handling has been removed from code template
expansion.
This can be useful when reusing thermo configurations across multiple
setups. In one simulation, the fluid might be entirely air, and in
another there might be additional pollutant or fuel species. This could
be defined without changing the species' thermo enties as follows:
"(mixture|air)"
{
specie
{
molWeight 28.9;
}
thermodynamics
{
Hf 0;
Cv 724.8;
}
transport
{
mu 1.84e-05;
Pr 0.7;
}
}
This was semi-supported before, but it lead to the wrong name (i.e., the
wildcard string) being stored in the base specie class. Now the name is
passed through the thermo constructors, so it is always correct.
This new class hierarchy replaces the distributions previously provided
by the Lagrangian library.
All distributions (except fixedValue) now require a "size exponent", Q,
to be specified along with their other coefficients. If a distribution's
CDF(x) (cumulative distribution function) represents what proportion of
the distribution takes a value below x, then Q determines what is meant
by "proportion":
- If Q=0, then "proportion" means the number of sampled values expected
to be below x divided by the total number of sampled values.
- If Q=3, then "proportion" means the expected sum of sampled values
cubed for values below x divided by the total sum of values cubed. If
x is a length, then this can be interpreted as a proportion of the
total volume of sampled objects.
- If Q=2, and x is a length, then the distribution might represent the
proportion of surface area, and so on...
In addition to the user-specification of Q defining what size the given
distribution relates to, an implementation that uses a distribution can
also programmatically define a samplingQ to determine what sort of
sample is being constructed; whether the samples should have an equal
number (sampleQ=0), volume (sampleQ=3), area (sampleQ=2), etc...
A number of fixes to the distributions have been made, including fixing
some fundamental bugs in the returned distribution of samples, incorrect
calculation of the distribution means, renaming misleadingly named
parameters, and correcting some inconsistencies in the way in which
tabulated PDF and CDF data was processed. Distributions no longer
require their parameters to be defined in a sub-dictionary, but a
sub-dictionary is still supported for backwards compatibility.
The distributions can now generate their PDF-s as well as samples, and a
test application has been added (replacing two previous applications),
which thoroughly checks consistency between the PDF and the samples for
a variety of combinations of values of Q and sampleQ.
Backwards incompatible changes are as follows:
- The standard deviation keyword for the normal (and multi-normal)
distribution is now called 'sigma'. Previously this was 'variance',
which was misleading, as the value is a standard deviation.
- The 'massRosinRammler' distribution has been removed. This
functionality is now provided by the standard 'RosinRammler'
distributon with a Q equal to 0, and a sampleQ of 3.
- The 'general' distribution has been split into separate distributions
based on whether PDF or CDF data is provided. These distributions are
called 'tabulatedDensity' and 'tabulatedCumulative', respectively.
This checks the consistency of incGamma and invIncGamma. It writes files
with columns containing values for different 'a' parameters. The
incGammaRatio_P.xy and invIncGammaRatio_P.xy files should generate the same
lines when the plot axis order is reversed. E.g., in gnuplot:
plot "incGammaRatio_P.xy" us 1:5 w l, \
"invIncGammaRatio_P.xy" us 5:1 w p
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.
A set of routines for cutting polyhedra have been added. These can cut
polyhedral cells based on the adjacent point values and an iso-value
which defines the surface. The method operates directly on the
polyhedral cells; it does not decompose them into tetrahedra at any
point. The routines can compute the cut topology as well as integrals of
properties above and below the cut surface.
An iso-surface algorithm has been added based on these polyhedral
cutting routines. It is significantly more robust than the previous
algorithm, and produces compact surfaces equivalent to the previous
algorithm's maximum filtering level. It is also approximately 3 times
faster than the previous algorithm, and 10 times faster when run
repeatedly on the same set of cells (this is because some addressing is
cached and reused).
This algorithm is used by the 'isoSurface', 'distanceSurface' and
'cutPlane' sampled surfaces.
The 'cutPlane' sampled surface is a renaming of 'cuttingPlane' to make
it consistent with the corresponding packaged function. The name
'cuttingPlane' has been retained for backwards compatibility and can
still be used to select a 'cutPlane' surface. The legacy 'plane' surface
has been removed.
The 'average' keyword has been removed from specification of these
sampled surfaces as cell-centred values are no longer used in the
generation of or interpolation to an iso-surface. The 'filtering'
keyword has also been removed as it relates to options within the
previous algorithm. Zone support has been reinstated into the
'isoSurface' sampled surface. Interpolation to all these sampled
surfaces has been corrected to exactly match the user-selected
interpolation scheme, and the interpolation procedure no longer
unnecessarily re-generates data that is already available.
The nearest, matching and inverseDistance methods are now based on a
shared "nearby" method. This method creates, for each face, a local
stencil of opposing faces for which the bounding spheres overlap. This
has proven far more robust on cases with both conformal and
non-conformal interfaces.
Topology change occurs before the time-increment and hence the oldest time
field (old-time in the case of 1st order time schemes, old-old-time in the case
of 2nd-order time schemes) is not actually needed as it is replaced by the
current time-field after time-increment so there is no purpose to mapping this
field. However, it is necessary to keep track of the existence of the
oldest-time field to ensure the correct number of old-time fields are cached for
the time-scheme. This development allows fvMesh to delete the redundant
oldest-time fields in such a manner that GeometricField can reinstate them
correctly after time-increment which is more efficient and more reliable than
attempting to map them and done previously.
Additionally fvMesh movement, which occurs after time-increment, now ensure all
old-time fields are up-to-date before NCC stitcher mapping so that both fields
and their old-time values are mapped consistently. This removes the need for
old-time field caching calls in MapGeometricFields, fvMeshAdder and
fvMeshStitcher, thus simplifying the code and improving maintainability.
avoiding problems with mesh generation, pre/post-processing applications
etc. triggering inappropriate changes to the moving and topoChanged states which
are only needed for updates in solvers corresponding to mesh changes.
The topoChanged flag now indicates that the mesh topology has changed at the
start of the current time-step rather than it is changing during the run, for
subsequent time-steps without topology change it is set false until the next
topology change.
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.
